目前我正在开发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中实现like / different结构：
案例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
和案例B :(“喜欢”是它自己的资源)
POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy
在这两种情况下我都有一个用户会话,所以在删除/“unliking”时我不必提及相应的“like”-record的id.
我想知道你们是如何实施这些案件的！
2011年4月15日更新：使用“会话”我的意思是与每个请求一起发送HTTP基本身份验证标头并提供加密的用户名：密码组合.
解决方法
我认为你在服务器上维护应用程序状态(包含用户id的用户会话)的事实是这里的问题之一.这使得它比它需要的更加困难,并且它打破了REST的无状态约束.
在案例A中,您已经为操作提供了URI,这也不是RESTful. URI标识资源,并且应使用所有资源共有的统一接口来执行状态转换.我认为案例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个喜欢！”).