REST 中的操作与 CRUD
除了简单的创建 (POST)、读取 (GET)、更新 (PUT) 和删除 (DELETE) 之外，是否适合使用 REST 执行操作？我对整个 RESTful 神学有点陌生，所以请耐心等待，但我应该如何完成以下任务：
- 我有一个 Web 服务需要与另一个 Web 服务通信。 Web 服务A 需要在Web 服务B 上“保留”一个对象。该对象有一个有效期超时，但如果需要可以立即删除。它本质上是一个美化的权限系统，要求 Web 服务在采取任何操作之前在 Web 服务 B 上预留空间。
我最初的想法是 1. 启用某种身份验证，2. 在服务器端响应 GET 调用时，保留空间并返回结果，3. 通过 DELETE 调用立即“取消保留”对象。这还是 RESTful 吗？
Is it appropriate to perform actions with REST, other than simple create (POST), read (GET), update (PUT), and delete (DELETE)? I'm kind of new to the whole RESTful theology, so bear with me, but how should I accomplish the following:
- I have a web service that needs to talk to another web service. Web service A needs to "reserve" an object on Web service B. This object has a timeout of validity, but can be deleted immediately if need be. It's essentially a glorified permissions system which requires web services to reserve a space on web service B before taking any actions.
My initial thought was to 1. enable authentication of some sort, 2. in the serverside response to a GET call, reserve the space and return the result, and 3. provide immediate "unreservation" of the object via a DELETE call. Is this still being RESTful?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，休息时执行操作是可以的。重要的是这些行动应该以你们交换的陈述为指导。
如果您考虑一下网络的工作方式（通过浏览器），您就会一直这样做：您会得到一个 HTML 表单，让您选择可以执行的许多操作。然后，您提交表单（通常通过
POST）并执行操作。能够通过编程客户端使用
DELETE是件好事（这是浏览器中的非 AJAX 请求不支持的），但是 RESTful 系统的整体方法应该与您找到网站（即重点应该放在表示上：相当于系统中的网页）。GET不应该有副作用，因此不要使用GET本身进行预订，而是使用POST之类的内容。Yes, it's OK to perform actions with rest. What matters is that these actions should be guided by the representations you exchange.
If you think about the way the web works (via a browser), you do this all the time: you get an HTML form that lets you choose a number of actions you can perform. Then, you submit the form (typically via
POST) and the action is performed.It's good to be able to use
DELETEvia a programmatic client (which is something that non-AJAX requests in browsers wouldn't support), but the overall approach of a RESTful system should be very similar to what you find for websites (i.e. the focus should be on the representations: the equivalent of web pages in your system).GETshouldn't have side effects, so don't useGETto make the reservation itself, use something likePOSTinstead.不 - 不太可能平静
根据您的描述...
2。在服务器端对 GET 调用的响应中，保留空间并返回结果
GET 应该是幂等的。仅出于这个原因，您的服务不太可能是静态的，因为第一次 GET 后系统的状态不同。
您确实需要考虑 Reservation 是一种资源，并且应该使用 POST 到预订容器来创建，该容器将在 HTTP 响应的 Location 标头中返回新资源的 URI。 Get 可以使用此 UrI 返回资源，并使用 PUT 进行更新
Post 应该用于扩展现有资源，而 Put 则用于替换资源的状态。在您的情况下，请考虑将 Post 用于更新预订列表并返回新资源的 URI（不仅仅是 Id）。 Put 可用于更改与 UR 标识的资源关联的状态
No - unlikely to be restful
From your description ...
2. in the serverside response to a GET call, reserve the space and return the result
GETs should be idempotent. For this reason alone, your service is unlikely to be restful because the state of the system after the first GET is different.
You really need to consider that a Reservation is a resource and should be created with a POST to a reservations container which will return the URI of the new resource in the Location header of the HTTP response. This UrI can be used by Get to return the resource and updated with a PUT
Post should be used to extend an existing resource and Put for replacing the state of a resource. In your case, consider the Post to be updating a list of Reservations and returning the URI of the new resource (not just the I'd). Put can be used for changing the state associated with the resource identified by the UR
您走在正确的轨道上，但您对对象的保留应该通过 PUT 进行；您正在对对象进行保留，即更改底层对象。
PUT 在这里是正确的动词，因为您知道要修改的资源，并且它对于多个请求应该是幂等的。
You're on the right track, but your reservation of the object should be with a PUT; you're PUTting a reservation on the object, i.e. changing the underlying object.
PUT is the right verb here, since you know what resource you're modifying, and it should be idempotent for multiple requests.