目前我正在开发一个API，在该API中，我希望登录用户能够喜欢/不喜欢或喜欢/不喜欢两个资源。
我的"Like"模型(它是一个Ruby on Rails 3应用程序)是多态的，属于两个不同的资源:
/api/v1/resource-a/:id/likes
和
/api/v1/resource-a/:resource_a_id/resource-b/:id/likes
问题是:我不知道该选择什么方法来使我的资源尽可能的RESTful。我已经尝试了下面两种方法来实现像/不像我的URL的结构:
情形A:(类似/不像"资源"的成员)
PUT /api/v1/resource/:id/like maps to Api::V1::ResourceController#like
PUT /api/v1/resource/:id/unlike maps to Api::V1::ResourceController#unlike
和case B:("likes"本身就是一个资源)
POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create
DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy
在这两种情况下，我已经有一个用户会话，所以在删除/"不喜欢"时，我不必提及相应的"喜欢"记录的id。
我想知道你们是如何实现这种情况的!
2011年4月15日更新:与"session"我的意思是HTTP基本认证头被发送与每个请求，并提供加密的用户名:密码组合。
我认为在服务器上维护应用程序状态(包含用户id的用户会话)是这里的问题之一。这使得这比它需要的困难得多，而且它打破了REST的无状态约束。
在情况A中，您已经为操作提供了uri，这同样不是RESTful。uri标识资源，状态转换应该使用对所有资源通用的统一接口来执行。我认为Case B在这方面要好得多。
因此，考虑到这两件事，我建议这样做:PUT /api/v1/resource/:id/likes/:userid
DELETE /api/v1/resource/:id/likes/:userid
我们还有一个额外的好处，即用户只能注册一个"喜欢"(他们可以重复"喜欢"多少次，因为PUT是幂等的，它有相同的结果，无论它执行多少次)。DELETE也是幂等的，所以如果一个"不像"操作由于某种原因被重复了很多次，那么系统保持在一个一致的状态。当然你可以用这种方式实现POST，但是如果我们使用PUT和DELETE，我们可以看到与这些动词相关的规则似乎非常适合我们的用例。
我还能想到另一个有用的请求:
GET /api/v1/resource/:id/likes/:userid
这将返回"喜欢"的详细信息，例如制作日期或序号(例如:"这是第50个赞!")。
情况B更好，这里有一个很好的示例来自GitHub API。
-
* a repo
/用户/主演:所有者/:回购
-
撤销repo
删除/用户/主演:所有者/:回购
您实际上定义了一个"喜欢"资源，即用户资源喜欢系统中的某些其他资源。因此，在REST中，您需要选择唯一标识这一事实的资源名称方案。我建议(以歌曲为例):
/like/user/{user-id}/song/{song-id}
PUT建立一个喜欢，DELETE删除它。GET当然会发现某人是否喜欢某首歌。您可以将GET /like/user/{user-id}定义为查看特定用户喜欢的歌曲列表，将GET /like/song/{song-id}定义为查看喜欢特定歌曲的用户列表。
如果您假设用户名是由现有会话建立的，正如@joelittlejohn指出的那样，并且不是类似资源名的一部分，那么您就违反了REST的无状态约束，并且您失去了一些非常重要的优势。例如，用户只能得到自己的点赞，而不能得到朋友的点赞。此外，它会破坏HTTP缓存，因为一个用户的点赞与另一个用户的点赞是无法区分的。