剩下的路，检查/取消选中喜欢/不象喜欢/不喜欢的资源 [英] The REST-way to check/uncheck like/unlike favorite/unfavorite a resource

问题描述

目前我正在开发一个API和API中我想在用户的签约能够喜欢/不象或喜欢/不喜欢的两个资源。

Currently I am developing an API and within that API I want the signed in users to be able to like/unlike or favorite/unfavorite two resources.

我喜欢模式（这是on Rails的Ruby的3个应用程序）是多态的，属于两个不同的资源：

My "Like" model (it's a Ruby on Rails 3 application) is polymorphic and belongs to two different resources:

/api/v1/resource-a/:id/likes

和

/api/v1/resource-a/:resource_a_id/resource-b/:id/likes

问题是：我在怀疑选择什么样的方式让我的资源尽可能宁静。我已经试了下两种方式来实现像/不像我的URL结构：

The thing is: I am in doubt what way to choose to make my resources as RESTful as possible. I already tried the next two ways to implement like/unlike structure in my URL's:

方案A：（如/不像是资源的成员）

Case A: (like/unlike being the member of the "resource")

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：（喜欢，是它自己的一个资源）

and case B: ("likes" is a resource on it's own)

POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create
DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy

在这两种情况下，我已经有一个用户会话，所以我没有提到相应的像-record时删除/取消顶的标识。

In both cases I already have a user session, so I don't have to mention the id of the corresponding "like"-record when deleting/"unliking".

我想知道你们已经实现了这样的情况！

I would like to know how you guys have implemented such cases!

更新2011年4月15日：在会话我的意思是HTTP基本认证头与每个请求被发送，并提供加密的用户名：密码组合

Update April 15th, 2011: With "session" I mean HTTP Basic Authentication header being sent with each request and providing encrypted username:password combination.

推荐答案

我认为你在服务器（包含用户ID的用户会话）维护应用程序状态的事实是这里的问题之一。它使这个有很多比它必须和它打破更难一个REST的的无国籍的约束。

I think the fact that you're maintaining application state on the server (user session that contains the user id) is one of the problems here. It's making this a lot more difficult than it needs to be and it's breaking a REST's statelessness constraint.

在方案A ，你已经给URI来操作，而这又是不是RESTful的。的URI标识的资源和应用一个统一的接口是通用于所有资源执行状态转换。我觉得情况B 在这方面好多了。

In Case A, you've given URIs to operations, which again is not RESTful. URIs identify resources and state transitions should be performed using a uniform interface that is common to all resources. I think Case B is a lot better in this respect.

所以，在考虑这两件事，我建议是这样的：

So, with these two things in mind, I'd propose something like:

PUT /api/v1/resource/:id/likes/:userid
DELETE /api/v1/resource/:id/likes/:userid

我们也有额外的好处，一个用户只能注册一个喜欢（他们可以重复'像'很多次，因为他们喜欢的，因为 PUT 是幂等它具有相同的结果，不管它是多少次执行）。 删除也是幂等的，因此如果'不像'操作重复许多次因为某些原因，然后系统仍处于一致的状态。当然，你可以实施 POST 以这种方式，但是如果我们使用 PUT 和删除我们可以看到，与这些词相关联的规则似乎符合我们的使用情况非常好。

We also have the added benefit that a user can only register one 'Like' (they can repeat that 'Like' as many times as they like, and since the PUT is idempotent it has the same result no matter how many times it's performed). DELETE is also idempotent, so if an 'Unlike' operation is repeated many times for some reason then the system remains in a consistent state. Of course you can implement POST in this way, but if we use PUT and DELETE we can see that the rules associated with these verbs seem to fit our use-case really well.

我也可以想像另一个有用的要求：

I can also imagine another useful request:

GET /api/v1/resource/:id/likes/:userid

这将返回细节'像'，如它的日期或序数（即这是第50个赞！'）

That would return details of a 'Like', such as the date it was made or the ordinal (i.e. 'This was the 50th like!').

这篇关于剩下的路，检查/取消选中喜欢/不象喜欢/不喜欢的资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！