RESTful 操作、服务器端操作
好的，我有一个支付系统。让我们忽略周围的一切，专注于支付本身。
通过一群向导，我建立了特定的付款。
首先，我做了一个
POST /付款
服务器返回
地点/付款/{id}
第一个向导页面：
PUT /付款/{id}
服务器返回
201（已创建）
后续向导页面：
PUT /付款/{id} 和 POST /付款/{id}/{子资源}
服务器返回
202（接受）用于 PUT 和 201（已创建）子资源
最后一页（只有摘要和“你确定吗”）
这是我的问题，我应该使用什么作为 REST 端点？
PUT /付款/{id}/流程
显然是错误的，因为 process 是一个动词，而不是资源。
PUT /付款/{id}
意味着客户端将进行处理，这是服务器不信任的。
PUT /付款/{id}
状态已更改（更改为“待处理”之类的内容），并且拦截该状态更改似乎非常老套，根本不是一个好的设计。
有人还有其他想法吗？
Ok, I've got a Payment system. Let's ignore everything around it, and focus on the Payment itself.
Through a bunch of wizards, I build up a particular payment.
First, I do a
POST /payment
server returns
LOCATION /payment/{id}
first Wizard page:
PUT /payment/{id}
server returns
201 (Created)
Subsequent wizard page:
PUT /payment/{id} and
POST /payment/{id}/{subresource}
server returns
202 (accepted) for the PUTs and
201 (Created) for the subresources
Last page (has nothing but a summary and an "are you sure")
Here's my question, what should I use as the REST endpoint?
PUT /payment/{id}/process
is plainly wrong, because process is a verb, not a resource.
PUT /payment/{id}
implies the client is going to do the processing, which is something the server does not trust.
PUT /payment/{id}
with the status changed (to something like "To Process") and having that status change be intercepted seems very hacky and not good design at all.
Anyone have other ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先对付款进行 GET：
获取该表示并将其 POST 到处理资源
Location 标头可以包含指向某些显示处理状态的资源的链接。
First do a GET of the payment:
Take that representation and POST it to a processing resource
The Location header can contain a link to some resource that shows the status of the processing.