在REST API中使用LINK和UNLINK HTTP谓词

Question

我目前正致力于实现REST API.我有一个资源模型,在各个资源之间有很多关系.

我的问题是:如何以RESTful方式将两个现有资源相互链接(建立关系)？

我遇到的一个解决方案是使用LINK和UNLINK HTTP动词.API使用者可以使用LINK和以下URI链接两个资源:/ resource1 /:id1/resource2 /:id2.

此解决方案的问题是缺少对LINK和UNLINK动词的支持.http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html或http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol都没有提到动词,它们似乎在很大程度上被"遗忘"了.但是,最初的RFC 2068确实声明它们存在.

我非常喜欢这个解决方案.但是,由于缺乏对LINK/UNLINK的支持,我担心许多API消费者/客户将无法处理该解决方案.这是一个可接受的解决方案,还是有更好的和/或更优雅的解决方案来链接RESTful API中的现有资源？

谢谢

Answer 1

我用LINK与UNLINK我(定制,公司内部)的Web应用程序.我使用http://tools.ietf.org/html/draft-snell-link-method作为我的实现参考.

我发现有三种类型的客户端:

1. 那些只支持GET并POST从HTML <form>元素中获取线索的人.
2. 那些仅支持GET,PUT,POST和DELETE.这些从CRUD和RPC假装成REST类型API中获取线索.
3. 那些允许任何方法.PATCH作为官方RFC 的出版增加了这些数量,WebDAV的增长也是如此,尽管有时候第2类客户也支持PATCH.

由于我们目前在内部开发我们的客户,我们没有这个问题,但我已经调查过并在定义我的API之前考虑了利弊,以防我们确实想要允许第三方客户.我的解决方案(因为我们需要支持没有Javascript的HTML客户端)是允许POST通过提供_METHODfield(application/x-www-form-urlencoded)来覆盖该方法,然后将我post()的后端掌上的函数关闭到预期的HTTP方法的相应函数.这样的话,在未来的是,比方说,2级以上的任何客户端,可以使用PUT和DELETE,但包裹PATCH,LINK并UNLINK在POST请求.您可以获得两全其美的优势:来自支持它的客户端的丰富方法,但仍然通过POST隧道支持低质量客户端.