以RESTful方式增加资源计数器:PUT vs POST?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (17)

我有一个拥有计数器的资源。为了举例,我们调用资源配置文件,计数器是该配置文件的视图数量。

根据REST wiki,PUT请求应该用于资源创建或修改,并且应该是幂等的。如果我正在更新配置文件的名称,那么这个组合很好,因为我可以发出一个PUT请求,它将名称设置为1000次,结果不会改变。

对于这些标准的PUT请求,我有浏览器执行如下操作:

PUT /profiles/123?property=value&property2=value2

为了增加一个计数器,可以这样调用url:

PUT /profiles/123/?counter=views

每次通话都会导致计数器递增。从技术上讲,这是一个更新操作,但它违反了幂等性。

我在寻找指导/最佳实践。你只是做这个POST吗?

提问于
用户回答回答于

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

要查看个人资料的所有查看内容:

GET / profiles / 123 /观看

要将观看添加到个人资料:

POST / profiles / 123 / viewsings#在这里,您可以使用请求正文中的自定义媒体类型提交详细信息。

要更新现有的查看:

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

深入查看详情:

GET /观看/ 815

删除查看:

删除/查看/ 815

另外,因为你要求最佳实践,请确保你的RESTful系统是超文本驱动的

在大多数情况下,在URI中使用查询参数没有任何问题 - 只是不要让客户想到他们可以操纵它们。

相反,创建一个媒体类型,体现参数试图建模的概念。给这个媒体类型一个简洁,明确,描述性的名字。然后记录这种媒体类型。在REST中公开查询参数的实际问题是,这种做法通常会导致带外通信,因此会增加客户端与服务器之间的耦合。

然后给你的系统一个统一的界面。例如,添加新资源始终是POST。更新资源总是PUT。删除是DELETE,getiing是GET。

关于REST最难的部分是理解媒体类型如何影响系统设计(这也是Fielding因为时间耗尽而留在他的论文中的部分)。如果你需要使用和配置媒体类型的超文本驱动系统的特定示例。

用户回答回答于

RFC 2068说得很好:

PATCH方法类似于PUT,不同之处在于实体包含在应用PATCH操作之后由Request-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在语法上都是有效的(但可能在语义上被禁止)。

扫码关注云+社区