问以RESTful方式递增资源计数器: PUT与POST

EN

另一种方法可能是向系统添加另一个资源，以跟踪配置文件的查看情况。你可以称之为“查看”。

要查看配置文件的所有视图，请执行以下操作：

GET /profile/123/viewings

要将查看添加到配置文件中：

POST /profile/123/viewings#在这里，您需要在请求正文中使用自定义媒体类型提交详细信息。

要更新现有查看：

PUT /viewings/815 #使用您创建的自定义媒体类型在请求正文中提交修改后的观看属性。

要深入查看详细信息，请执行以下操作：

GET /viewings/815

要删除查看：

删除/查看/815

另外，因为您要求的是最佳实践，所以请确保您的RESTful系统是hypertext-driven。

在大多数情况下，在URI中使用查询参数没有错-只是不要让您的客户认为他们可以操作它们。

相反，应该创建一个媒体类型，它体现了参数试图建模的概念。为此媒体类型指定一个简洁、明确且具有描述性的名称。然后记录此媒体类型。在REST中公开查询参数的真正问题是，这种做法经常导致带外通信，从而增加了客户端和服务器之间的耦合。

然后给你的系统一个统一的界面。例如，添加新资源始终是一个帖子。更新资源总是一个PUT。DELETE为DELETE，GET为GET。

关于REST最难的部分是理解媒体类型如何融入系统设计(这也是Fielding在他的论文中遗漏的部分，因为他的时间已经用完了)。如果您想要一个使用和转换媒体类型的超文本驱动系统的特定示例，请参阅Sun Cloud API。

我认为正确的答案是使用PATCH。我没有看到其他人推荐使用它来自动递增计数器，但我相信RFC 2068说得很好：

补丁方法与PUT类似，只是实体包含由请求URI标识的资源的原始版本与应用补丁操作后所需的资源内容之间的差异列表。差异列表是由实体的媒体类型(例如，"application/diff")定义的格式，并且必须包括足够的信息以允许服务器重新创建将资源的原始版本转换为所需版本所需的改变。

因此，要更新配置文件123的视图计数，我将：

PATCH /profiles/123 HTTP/1.1
Host: www.example.com
Content-Type: application/x-counters

views + 1

其中，x-counters媒体类型(我刚刚编写的)由多行field operator scalar元组组成。views = 500、views - 1或views + 3在语法上都是有效的(但在语义上可能是被禁止的)。

我可以理解一些皱眉-在编造另一种媒体类型时，但我谦虚地建议它比POST / PUT替代方案更正确。为一个字段构建一个资源，包括它自己的URI，特别是它自己的细节(我并不真正保存这些细节，我只有一个整数)，这对我来说听起来是错误的，也是很麻烦的。如果我有23个不同的计数器要维护怎么办？

在评估了前面的答案后，我决定PATCH是不合适的，并且，就我的目的而言，为了一个微不足道的任务而摆弄内容类型是违反KISS principle的。我只需要递增n+1，所以我就这样做了：

PUT /profiles/123$views
++

其中++是消息体，控制器将其解释为将资源递增1的指令。

我选择$来界定资源的字段/属性，因为它是一个legal sub-delimiter，而且，就我的目的而言，它似乎比/更直观，在我看来，它具有可遍历的感觉。