通过重载 POST 与嵌入 URI 来模拟操作
我目前正在阅读 Restful Java & Restful Web Services 和有关 REST 的风格问题，这两本书似乎不一致。具体来说，如何更改资源的状态。
Restful Java 有一个可以取消订单的示例。它提出将 cancelled=true 添加到 PUT 请求中的表示中以进行状态转移。所以你会有这样的东西。
PUT /orders/333 HTTP/1.1
Content-Type: application/xml
<order id="333">
<...>
<cancelled>true</cancelled>
</order>
然后它建议将其作为嵌入订单中的单独 uri（或作为链接：http 标头）进行处理，
PUT /orders/333 HTTP/1.1
Content-Type: application/xml
<order id="333">
<...>
<link rel="cancel" href="http://example.com/orders/333/cancelled">
</order>
这对我来说很有意义，直到我阅读了《Restful Web Services》一书，该书似乎倾向于发布 cancelled=true到一个超载的 POST。
我倾向于喜欢 /orders/333/cancelled 因为我可以很容易地发现有一种方法可以使用链接来执行此操作，我只是好奇这是否是一个好的做法或者是否有更好的方法？
谢谢， 赎金
I am currently reading Restful Java & Restful Web Services and have a style question about REST where these two books seem to disagree. Specifically what to do about changing the state of the resource.
Restful Java has an example of an order that can be cancelled. It presents adding cancelled=true to the representation in a PUT request to make a state transfer. So you would have something like this.
PUT /orders/333 HTTP/1.1
Content-Type: application/xml
<order id="333">
<...>
<cancelled>true</cancelled>
</order>
Then it proposes instead doing it as a separate uri embedded in the order (or as a Link: http header)
PUT /orders/333 HTTP/1.1
Content-Type: application/xml
<order id="333">
<...>
<link rel="cancel" href="http://example.com/orders/333/cancelled">
</order>
This made sense to me, until I read the Restful Web Services book which seems to fall on the side of posting the cancelled=true to an overloaded POST.
I tend to like the /orders/333/cancelled because I can easily expose that there is a way to take this action using links, I am just curious as to if this is a good practice or if there is a better way?
Thanks,
Ransom
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
创建“已取消”URL 的“问题”在于，取消订单的行为从技术上讲并不是一种资源。这意味着取消不是其自己的资源 - 它只是修改现有订单资源的一种方式。如果您想成为 RESTful，那么您应该避免此路径并支持在主体内使用取消属性的 PUT，或者您可以使用 PATCH 支持部分更新（尽管此 HTTP 动词的支持不如 PUT 广泛）。
另一种选择是创建“操作”资源。该操作将定义您可以对订单执行的操作类型，例如取消、复制、关闭等。但这往往很重要并且可能没有必要，除非您开始进行批量操作。那么这项技术非常强大，也是我发现的以 REST 方式对批量操作进行建模的唯一方法。
当然，你总是可以忽略纯粹主义者，并说你不在乎你的服务是否是 RESTful。如果您只想使用原始 HTTP 接口公开此动词，那么，这取决于您。
The "problem" with creating a "cancelled" URL is that the act of cancelling an order isn't technically a resource. Meaning that the cancellation isn't its own resource - it's simply a way of modifying the existing order resource. If you want to be RESTful, then you should avoid this path and support PUT with the cancelled property inside the body, or you could support a partial update with PATCH (although this HTTP verb is less widely supported than PUT).
Another option would be to create an "operation" resource. That operation would define the kinds of things you can do to your order, e.g. cancel, duplicate, close, etc. But this tends to be heavy weight and potentially unnecessary, unless you're starting to get into bulk operations. Then this technique is pretty powerful and the only way I've found to RESTfully model bulk ops.
Of course, you can always ignore the purists and say you don't care whether or not your service is RESTful. If all you want is to expose this verb with a raw HTTP interface, well, that's up to you.
URI 的外观远不如
rel="Cancel"部分重要，这才是客户端真正应该关心的。如果您想避免人们说您在 URL 中放入了动词，那么只需将您的 URI 更改为或
关于建议的替代方法，我个人不太喜欢 PUT 来更改状态。对于状态更新，我喜欢 POST 到已过滤的状态集合。
What the URI looks like is far less important than the
rel="Cancel"part, that's all the client should really care about. If you want to avoid people saying you are putting verbs in your URL, then just change your URI toor
Regarding the alternative approach suggested, personally I'm not a big fan of the PUT to change status. For status updates, I like to POST to a filtered status collection.