blocks|key|3089738|text|另一种方法可能是向系统添加另一个资源，以跟踪配置文件的查看情况。你可以称之为“查看”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089739|要查看配置文件的所有视图，请执行以下操作：|3089740|GET+/profile/123/viewings|3089741|要将查看添加到配置文件中：|3089742|POST+/profile/123/viewings#在这里，您需要在请求正文中使用自定义媒体类型提交详细信息。|3089743|要更新现有查看：|3089744|PUT+/viewings/815+#使用您创建的自定义媒体类型在请求正文中提交修改后的观看属性。|3089745|要深入查看详细信息，请执行以下操作：|3089746|GET+/viewings/815|3089747|要删除查看：|3089748|删除/查看/815|3089749|另外，因为您要求的是最佳实践，所以请确保您的RESTful系统是hypertext-driven。|offset|length|3089750|在大多数情况下，在URI中使用查询参数没有错-只是不要让您的客户认为他们可以操作它们。|3089751|相反，应该创建一个媒体类型，它体现了参数试图建模的概念。为此媒体类型指定一个简洁、明确且具有描述性的名称。然后记录此媒体类型。在REST中公开查询参数的真正问题是，这种做法经常导致带外通信，从而增加了客户端和服务器之间的耦合。|3089752|然后给你的系统一个统一的界面。例如，添加新资源始终是一个帖子。更新资源总是一个PUT。DELETE为DELETE，GET为GET。|3089753|关于REST最难的部分是理解媒体类型如何融入系统设计(这也是Fielding在他的论文中遗漏的部分，因为他的时间已经用完了)。如果您想要一个使用和转换媒体类型的超文本驱动系统的特定示例，请参阅Sun+Cloud+API。|3089754|entityMap|0|LINK|mutability|MUTABLE|url|http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven|1|http://kenai.com/projects/suncloudapis/pages/Home^0|0|0|0|0|0|0|0|0|0|0|0|W|G|0|0|0|0|0|2O|D|1|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1J|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1K|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1L|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1M|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1N|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1O|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1P|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1R|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1S|8|@]|9|@$X|1T|Y|1U|1|1V]]|A|$]]|$1|Z|3|10|5|6|7|1W|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1X|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1Z|8|@]|9|@$X|20|Y|21|1|22]]|A|$]]|$1|17|3|-4|5|6|7|23|8|@]|9|@]|A|$]]]|18|$19|$5|1A|1B|1C|A|$1D|1E]]|1F|$5|1A|1B|1C|A|$1D|1G]]]]

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:

GET /profiles/123/viewings

To add a viewing to a profile:

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 # 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:

GET /viewings/815

To delete a Viewing:

DELETE /viewings/815

Also, because you're asking for best-practice, be sure your RESTful system is <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="noreferrer">hypertext-driven</a>.

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.

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.

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.

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 <a href="http://kenai.com/projects/suncloudapis/pages/Home" rel="noreferrer">Sun Cloud API</a>.

blocks|key|331303|text|我认为正确的答案是使用PATCH。我没有看到其他人推荐使用它来自动递增计数器，但我相信RFC+2068说得很好：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|331304|331305|补丁方法与PUT类似，只是实体包含由请求URI标识的资源的原始版本与应用补丁操作后所需的资源内容之间的差异列表。差异列表是由实体的媒体类型(例如，"application/diff")定义的格式，并且必须包括足够的信息以允许服务器重新创建将资源的原始版本转换为所需版本所需的改变。|blockquote|331306|331307|331308|因此，要更新配置文件123的视图计数，我将：|331309|PATCH+/profiles/123+HTTP/1.1
Host:+www.example.com
Content-Type:+application/x-counters

views+%2B+1|code-block|syntax|javascript|331310|其中，x-counters媒体类型(我刚刚编写的)由多行field+operator+scalar元组组成。views+=+500、views+-+1或views+%2B+3在语法上都是有效的(但在语义上可能是被禁止的)。|style|CODE|331311|我可以理解一些皱眉-在编造另一种媒体类型时，但我谦虚地建议它比POST+/+PUT替代方案更正确。为一个字段构建一个资源，包括它自己的URI，特别是它自己的细节(我并不真正保存这些细节，我只有一个整数)，这对我来说听起来是错误的，也是很麻烦的。如果我有23个不同的计数器要维护怎么办？|331312|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc2068#section-19.6.1^0|17|8|0|0|0|0|0|0|0|0|3|A|S|L|1I|B|1U|9|24|9|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|-4|5|6|7|18|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|19|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1D|8|@]|9|@]|C|$O|P]]|$1|Q|3|R|5|6|7|1E|8|@$A|1F|B|1G|S|T]|$A|1H|B|1I|S|T]|$A|1J|B|1K|S|T]|$A|1L|B|1M|S|T]|$A|1N|B|1O|S|T]]|9|@]|C|$]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]]]

I think the right answer is to use PATCH. I didn't see anyone else recommending it should be used to atomically increment a counter, but I believe <a href="https://www.rfc-editor.org/rfc/rfc2068#section-19.6.1" rel="nofollow noreferrer">RFC 2068</a> says it all very well:
<blockquote>
The PATCH method is similar to PUT except that the entity contains a
list of differences between the original version of the resource
identified by the Request-URI and the desired content of the resource
after the PATCH action has been applied. The list of differences is
in a format defined by the media type of the entity (e.g.,
&quot;application/diff&quot;) and MUST include sufficient information to allow
the server to recreate the changes necessary to convert the original
version of the resource to the desired version.
</blockquote>
So, to update profile 123's view count, I would:
<pre><code>PATCH /profiles/123 HTTP/1.1
Host: www.example.com
Content-Type: application/x-counters

views + 1
</code></pre>
Where the <code>x-counters</code> media type (which I just made up) is made of multiple lines of <code>field operator scalar</code> tuples. <code>views = 500</code> or <code>views - 1</code> or <code>views + 3</code> are all valid syntactically (but may be forbidden semantically).
I can understand some frowning-upon making up yet another media type, but I humbly suggest it's more correct than the POST / PUT alternative. Making up a resource for a field, complete with its own URI and especially its own details (which I don't really keep, all I have is an integer) sounds wrong and cumbersome to me. What if I have 23 different counters to maintain?

blocks|key|333662|text|我认为Yanic和Rich的两种方法都是有趣的。补丁不需要是安全的或无能为力的，但可以是更健壮的，以对抗并发。Rich的解决方案当然更容易在“标准”REST+API中使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|333663|请参阅RFC5789|offset|length|333664|根据RFC2616，第9.1节的定义，|333665|补丁既不安全也不幂等。|blockquote|333666|333667|333668|补丁请求可以以幂等的方式发出，这也有助于防止相同资源上的两个补丁请求在类似的时间范围内发生冲突而产生不良结果。来自多个补丁请求的冲突可能比PUT冲突更危险，因为一些补丁格式需要从已知的基点操作，否则它们将破坏资源。|333669|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc5789^0|0|3|7|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

I think both approaches of Yanic and Rich are interresting. A PATCH does not need to be safe or indempotent but can be in order to be more robust against concurrency. Rich's solution is certainly easier to use in a &quot;standard&quot; REST API.
See <a href="https://www.rfc-editor.org/rfc/rfc5789" rel="nofollow noreferrer">RFC5789</a>:
<blockquote>
PATCH is neither safe nor idempotent as defined by [RFC2616], Section
9.1.
</blockquote>
A PATCH request can be issued in such a way as to be idempotent,
which also helps prevent bad outcomes from collisions between two
PATCH requests on the same resource in a similar time frame.
Collisions from multiple PATCH requests may be more dangerous than
PUT collisions because some patch formats need to operate from a
known base-point or else they will corrupt the resource.

blocks|key|333675|text|在评估了前面的答案后，我决定PATCH是不合适的，并且，就我的目的而言，为了一个微不足道的任务而摆弄内容类型是违反KISS+principle的。我只需要递增n%2B1，所以我就这样做了：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|333676|PUT+/profiles/123$views
%2B%2B|code-block|syntax|javascript|333677|其中%2B%2B是消息体，控制器将其解释为将资源递增1的指令。|style|CODE|333678|我选择$来界定资源的字段/属性，因为它是一个legal+sub-delimiter，而且，就我的目的而言，它似乎比/更直观，在我看来，它具有可遍历的感觉。|333679|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/KISS_principle|1|https://www.rfc-editor.org/rfc/rfc3986#section-2.2^0|1L|E|0|0|0|2|2|0|3|1|1L|1|M|J|1|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|13|8|@$A|14|B|15|K|L]]|9|@]|C|$]]|$1|M|3|N|5|6|7|16|8|@$A|17|B|18|K|L]|$A|19|B|1A|K|L]]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|O|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]|W|$5|R|S|T|C|$U|X]]]]

After evaluating the previous answers I decided PATCH was inappropriate and, for my purposes, fiddling around with Content-Type for a trivial task was a violation of the <a href="https://en.wikipedia.org/wiki/KISS_principle" rel="nofollow noreferrer">KISS principle</a>. I only needed to increment n+1 so I just did this:
<pre><code>PUT /profiles/123$views
++
</code></pre>
Where <code>++</code> is the message body and is interpreted by the controller as an instruction to increment the resource by one.
I chose <code>$</code> to deliminate the field/property of the resource as it is a <a href="https://www.rfc-editor.org/rfc/rfc3986#section-2.2" rel="nofollow noreferrer">legal sub-delimiter</a> and, for my purposes, seemed more intuitive than <code>/</code> which, in my opinion, has the vibe of traversability.

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.

Per the <a href="http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpMethods" rel="noreferrer">REST wiki</a>, 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.

For these standard PUT requests, I have browsers do something like:

<pre><code>PUT /profiles/123?property=value&amp;property2=value2
</code></pre>

For incrementing a counter, one calls the url like so:

<pre><code>PUT /profiles/123/?counter=views
</code></pre>

Each call will result in the counter being incremented. Technically it's an update operation but it violates idempotency.

I'm looking for guidance/best practice. Are you just doing this as a POST?

Incrementing resource counter in a RESTful way: PUT vs POST

服务器

我有一个有计数器的资源。为了便于示例，让我们将资源配置文件称为，计数器是该配置文件的视图的数量。根据，PUT请求应该用于资源创建或修改，并且应该是幂等的。如果我正在更新配置文件的名称，这种组合就很好，因为我可以发出一个PUT请求，将名称设置为某个值1000次，并且结果不会改变。对于这些标准的PUT请求，我让浏览器执行如...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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