以RESTful方式递增资源计数器:PUT和POST
问题说明
我有一个带有计数器的资源.举例来说，我们将资源称为 个人资料 ，而计数器就是该资源的 观看次数 个人资料.
I have a resource that has a counter. For the sake of example, let's call the resource profile, and the counter is the number of views for that profile.
对于 REST Wiki ，应将PUT请求用于资源创建或修改，并且应该是幂等的.如果我要更新配置文件的名称，那么这种组合就很好了，因为我可以发出一个PUT请求，将该请求的名称设置为1000倍，并且结果不会改变.
Per the REST wiki, PUT requests should be used for resource creation or modification, and should be idempotent. That combination is fine if I'm updating, say, the profile's name, because I can issue a PUT request which sets the name to something 1000 times and the result does not change.
对于这些标准的PUT请求，我让浏览器执行以下操作:
For these standard PUT requests, I have browsers do something like:
PUT /profiles/123?property=value&property2=value2
要增加一个计数器，可以这样调用网址:
For incrementing a counter, one calls the url like so:
PUT /profiles/123/?counter=views
每次调用都会导致计数器增加.从技术上讲，这是一个更新操作，但它违反了幂等性.
Each call will result in the counter being incremented. Technically it's an update operation but it violates idempotency.
我正在寻找指导/最佳实践.您只是在做POST吗?
I'm looking for guidance/best practice. Are you just doing this as a POST?
正确答案
一种替代方法是向系统添加另一个资源，以跟踪配置文件的视图.您可以将其称为正在查看".
An alternative might be to add another resource to the system to track the viewings of a profile. You might call it "Viewing".
要查看个人资料的所有查看:
To see all Viewings of a profile:
获取/profiles/123/观看次数
GET /profiles/123/viewings
要在个人资料中添加视图，请执行以下操作:
To add a viewing to a profile:
POST/profiles/123/viewings#在这里，您将使用请求正文中的自定义媒体类型提交详细信息.
POST /profiles/123/viewings #here, you'd submit the details using a custom media type in the request body.
要更新现有的观看内容，请执行以下操作:
To update an existing Viewing:
PUT/viewings/815#使用您创建的自定义媒体类型在请求正文中提交视图"的修订属性.
PUT /viewings/815 # submit revised attributes of the Viewing in the request body using the custom media type you created.
要深入查看视图的详细信息，请执行以下操作:
To drill down into the details of a viewing:
获取/viewings/815
GET /viewings/815
要删除观看内容，请执行以下操作:
To delete a Viewing:
删除/views/815
DELETE /viewings/815
此外，由于您要求最佳实践，因此请确保您的RESTful系统为超文本驱动.
Also, because you're asking for best-practice, be sure your RESTful system is hypertext-driven.
在大多数情况下，在URI中使用查询参数没有任何问题-只是不要让客户知道他们可以操纵它们.
For the most part, there's nothing wrong with using query parameters in URIs - just don't give your clients the idea that they can manipulate them.
相反，创建一种媒体类型，以体现参数正在尝试建模的概念.给此媒体类型一个简洁，明确和描述性的名称.然后记录此媒体类型.在REST中公开查询参数的真正问题是，这种做法经常导致带外通信，因此增加了客户端和服务器之间的耦合.
Instead, create a media type that embodies the concepts the parameters are trying to model. Give this media type a concise, unambiguous, and descriptive name. Then document this media type. The real problem of exposing query parameters in REST is that the practice often leads out-of-band communication, and therefore increased coupling between client and server.
然后为您的系统提供统一的界面.例如，添加新资源始终是POST.更新资源始终是PUT.删除就是DELETE，而getiing是GET.
Then give your system a uniform interface. For example, adding a new resource is always a POST. Updating a resource is always a PUT. Deleting is DELETE, and getiing is GET.
关于REST的最困难的部分是了解媒体类型如何进入系统设计(这也是Fielding由于时间不够而从他的论文中遗漏的部分).如果要使用和取消使用媒体类型的超文本驱动系统的特定示例，请参见 Sun Cloud API .
The hardest part about REST is understanding how media types figure into system design (it's also the part that Fielding left out of his dissertation because he ran out of time). If you want a specific example of a hypertext-driven system that uses and doucuments media types, see the Sun Cloud API.
这篇好文章是转载于：学新通技术网
