当从具有超媒体约束的 REST API 提供响应时,如何向客户端指示要使用哪个 HTTP 方法(动词)?

发布于 2024-11-14 02:34:14 字数 1423 浏览 4 评论 0原文

我认为我已经很好地掌握了 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" 的链接可以是 GETPUTDELETE 请求。带有 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

俯瞰星空 2024-11-21 02:34:14

简单的事实是,这些动词将记录在资源文档中。

您没有问的问题是,“客户如何知道参考‘订单’、‘发票’和‘付款’的用途?”。

然而,他们也面临着你所问的同样的问题。它们也需要记录下来。

当这些被记录下来,当这些关系被解释为它们是什么,它们为什么存在,以及你作为资源消费者将使用它们做什么时,那么利用这些资源所需的实际动词也将与它们一起记录下来。

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.

只是在用心讲痛 2024-11-21 02:34:14

客户端可以调用您公开的任何 URI 上的任何 HTTP 动词。这些行动是否会产生任何效果是一个单独的问题。

客户端可以以不同的方式发现哪些方法适用于特定的 URI:

  1. 它们使用不同的操作调用每个 URI,并动态地找出哪些方法有效(返回 2xx 响应代码)以及哪些方法返回 405 - 不允许的方法< /代码>。
  2. 客户端程序员会阅读您的文档并提前对交互进行编码。

老实说,我从未见过在生产系统中实现#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:

  1. They call each URI with the different actions and dynamically figure out which ones work (returning a 2xx response code) and which ones return 405 - Method Not Allowed.
  2. The client programmer reads your documentation and codes up the interactions ahead of time.

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文