当从具有超媒体约束的 REST API 提供响应时,如何向客户端指示要使用哪个 HTTP 方法(动词)?
我认为我已经很好地掌握了 RESTful 架构的原则,但我还没有做到这一点。
我似乎无法弄清楚的是,客户端如何知道每个资源可以使用哪些 HTTP 方法?当应用程序流程中需要执行特定操作才能继续流程时该怎么办?
简化示例:
假设客户向我的 REST API 下了一个简单的订单。
客户端将向以下位置发出发布请求:http://api.mycompany.com/orders
请求负载
<order>
<items>
<sku>12345</sku>
<quantity>1</quantity>
</items>
</order>
假设请求成功
响应负载
<order>
<id>156</id>
<status>Pending Payment</status>
<items>
<sku>12345</sku>
<quantity>1</quantity>
</items>
<links>
<link rel="order" url="http://api.mycompany.com/orders/156" />
<link rel="invoice" url="http://api.mycompany.com/payments/156" />
<link rel="payment" url="http://api.mycompany.com/invoices/156" />
</links>
</order>
如果我正确理解超媒体约束,我提供相应的资源,客户端可以选择从那里去哪里。
在上面的示例中,带有 rel="order" 的链接可以是 GET、PUT 或 DELETE 请求。带有 rel="invoice" 的链接仅限于 GET 请求。带有 rel=" payment" 的链接将只接受POST请求。
客户怎么知道这一点?我知道如果他们向上述资源之一发出OPTIONS请求,它应该为他们提供可用的方法,但我不确定这是否是处理这种情况的标准方法。
任何帮助将不胜感激。
I think I have a pretty good grasp on the tenets of a RESTful architecture but I'm not there yet.
The part that I can't seem to figure out is how do the clients become aware of which HTTP methods are available to each resource? What about when a specific action is required in the application flow to continue a process?
Simplified Example:
Assuming a client places a simple order to my REST API.
The client will make a post request to: http://api.mycompany.com/orders
Request Payload
<order>
<items>
<sku>12345</sku>
<quantity>1</quantity>
</items>
</order>
Assuming the request is successful
Response Payload
<order>
<id>156</id>
<status>Pending Payment</status>
<items>
<sku>12345</sku>
<quantity>1</quantity>
</items>
<links>
<link rel="order" url="http://api.mycompany.com/orders/156" />
<link rel="invoice" url="http://api.mycompany.com/payments/156" />
<link rel="payment" url="http://api.mycompany.com/invoices/156" />
</links>
</order>
If I understand the hypermedia constraint correctly, I provide corresponding resources and the client can choose where to go from there.
In the above example the link with rel="order" could be a GET, PUT, or DELETE request. The link with rel="invoice" is restricted to a GET request. The link with rel="payment" will only accept a POST request.
How does the client know this? I know if they make an OPTIONS request to one of the aforementioned resources it should give them the methods that are available but I'm not sure if that's the standard way of handling this kind of scenario.
Any help would be greatly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
简单的事实是,这些动词将记录在资源文档中。
您没有问的问题是,“客户如何知道参考‘订单’、‘发票’和‘付款’的用途?”。
然而,他们也面临着你所问的同样的问题。它们也需要记录下来。
当这些被记录下来,当这些关系被解释为它们是什么,它们为什么存在,以及你作为资源消费者将使用它们做什么时,那么利用这些资源所需的实际动词也将与它们一起记录下来。
The simple fact is that those verbs will be documented in the documentation of the resources.
The question you didn't ask is, "How does a client know what the refs 'order', 'invoice', and 'payment' are for?".
Yet, they suffer the same problem you're asking. And they, too, need to be documented as well.
When those are documented, when those rels are explained as to what they are, why they exist, and what you as a resource consumer would use them for, then the actual verbs necessary to leverage those resources would be documented with them as well.
客户端可以调用您公开的任何 URI 上的任何 HTTP 动词。这些行动是否会产生任何效果是一个单独的问题。
客户端可以以不同的方式发现哪些方法适用于特定的 URI:
405 - 不允许的方法< /代码>。
老实说,我从未见过在生产系统中实现#1。 #2 对我和大多数必须编写使用 REST API 的客户端的人来说最有意义。
请注意,使用 REST API 不仅仅需要知道要使用哪个 HTTP 动词。媒体类型的内容和结构(对于请求和响应)对于记录并提供给那些计划针对您的系统进行编码的人来说同样重要。
Clients can call any of the HTTP verbs on any URI you expose. Whether or not those actions will have any effect is a separate question.
Clients could discover which methods will work on a particular URI in different ways:
405 - Method Not Allowed
.I'll be honest, I've never seen #1 implemented in a production system. #2 is what makes most sense to me and most humans that have to write clients that consume a REST API.
Note that there is more to consuming a REST API than just knowing which HTTP verb to use. The content and structure of the media type (for both requests and responses) is just as important to document and make available to those who plan to code against your system.