gpt4 book ai didi

rest - 带有状态轮询的异步 ReST(以及如何最终接收完成的结果)

转载 作者:行者123 更新时间:2023-12-01 05:15:42 25 4
gpt4 key购买 nike

我有一个预计需要几个小时才能完成的请求,但我无法弄清楚整个流程。我知道这已经讨论过多次,包括 here ,但我发现没有任何东西可以回答以下问题(令人信服)。

我知道的:

  • 我会做POST /mysomethings
  • 响应将是 202 AcceptedLocation header 将包含可以找到状态的完整网址(例如 https://api.example.com/statuses/somestatusuuid )。
  • 然后客户端可以轮询状态 url 并获得 200 OK响应主体包含类似 { statusId: someid, status: somestatusstring, description: somestatusdescriptionstring } 的内容

  • 为了让事情变得简单和集中,我忽略了如何为这些请求进行授权。

    我的问题:

    一旦原始请求的资源准备好(假设这意味着 status="complete"),我该怎么办。

    我能想到的最好的是以下之一:
  • 状态响应还将包括(一旦 status="complete")一个附加键,例如 myresourceId: someuuid然后客户端可以做 GET /mysomethings/someuuid
  • 状态响应(一旦资源准备好)将包含一个带有资源完整 url 的 Location header (例如 https://api.example.com/mysomethings/someuuid )
  • 以上两者的组合,以便我同时拥有资源的 url 及其 ID

  • 一些额外的想法:
  • IMO 在状态请求中返回资源本身是不合适的,因为请求的是状态而不是实际资源。
  • 我也不喜欢在某些地方建议的想法,在资源准备好之前返回 202 作为状态,然后返回 201 Created 因为状态代码应该传达请求的状态,而不是资源的状态(绝对不是当前请求仅请求其状态的另一个资源)。

  • 这一切听起来对吗?欢迎任何和所有评论。

    最佳答案

    尽管您放弃了使用 HTTP 202 代码的选项,但您几乎描述了 RFC 2616 的情况。规范定义了使用 201/202 对 HTTP 响应。

    不是返回 HTTP 200 代码并使用 404,而是让服务器返回 HTTP 202(已接受)并编写客户端代码进行轮询,直到收到 HTTP 201(已创建),并在 Location header 中使用新的资源 URI(或超时期限)发生)。

    关于rest - 带有状态轮询的异步 ReST(以及如何最终接收完成的结果),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20867839/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com