Php 什么时候在API中返回305 Use代理合适？

这是我的第一个问题，请客气一点

在构建API时，您不时会遇到需要一段时间才能处理的请求。较长的API进程可能导致请求超时

（在我的例子中，PUT或POST方法涉及上传到第三方eBay并与之通信。这将创建或更新列表并返回响应信息。）

为了避免超时，我决定向用户发送一个带有URL的响应，用户可以查询最终结果。（我的想法来自于搜索，我在继续处理的同时返回HTTP响应，并用于设计概念：POST/PUT到一个地址，然后获取另一个地址。）

我希望这个“分叉”处理对于API请求是可选的，以便将来可以打开或关闭它这意味着API的用户可能只是收到了他们想要的结果，或者可能会得到一个不同的URL来最终获得结果。看来HTTP响应代码是处理这个问题的最佳方法。当您的结果按预期返回时返回200，当用户稍后应该访问另一个URL时返回其他内容

因此，选择正确的HTTP响应代码比我希望的要微妙一些（我想我可以使用自定义代码，314作为pi）。似乎应该使用3xx，因为这是一个重定向，但当我使用303时，浏览器会立即处理重定向，并且实际使用的时间也一样长（在chrome中使用POSTMAN）。使用307不合适，因为我希望下一个请求是GET而不是PUT或POST。自定义3xx仍由浏览器自动重定向。当我使用“305使用代理”时，一切正常。API的用户会立即得到响应，他们可以选择按自己认为合适的方式进行处理

所以这里有一个问题：依靠这种浏览器行为来使用代理（允许用户处理下一个调用）安全吗？如果不是，最好的替代代码是什么

回答暗示305未实施，可能会被弃用

W3C第305段说

必须通过Location字段提供的代理访问请求的资源。Location字段提供代理的URI收件人应通过代理重复此单个请求。305响应必须仅由源服务器生成

我认为这意味着正确的行为是委托接收者重复我想要的请求

说“我希望你不是在试图产生一个响应。”

---

我很高兴305的工作方式是这样的，所以我可以给你你的答案，或者让你决定什么时候为你的答案投票其他一些网址后，它可能会准备好。如果我能在不久的将来依靠这种行为，那就意味着不必处理WebSocket或排队等待长时间的任务或网关超时。我担心浏览器做我想做的事情是出于巧合，而不是出于设计，也许将来305会被删除，或者浏览器会像其他3xx一样自动重定向。我不希望使用4xx，因为它不是一个错误，但我可以接受它。

从外观上看，305与您尝试执行的操作不一致。通过代理重复请求与从不同位置请求资源或轮询URL不同

---

可能只是返回一个JSON对象，其中包含一个指向需要轮询的URL的链接，并记录该行为。没有人编写能够神奇地处理HTTP代码的API客户端（除了明显的404、200等），因此，如果需要比普通重定向更复杂的东西，则始终需要对其进行记录。

这正是“202已接受”状态代码的使用案例：

10.2.3 202已接受

请求已被接受以进行处理，但处理已完成 尚未完成。请求可能最终会被执行，也可能不会被执行 在上，因为在实际进行处理时可能不允许这样做。 没有从异步服务器重新发送状态代码的功能 像这样的操作

202号答复故意不作承诺。其目的是 允许服务器接受其他进程的请求（可能是 面向批处理的流程，每天只运行一次），没有 要求用户代理与服务器的连接持续到 这个过程已经完成。实体随此响应返回 应包括请求的当前状态和 一个指向状态监视器的指针，或者一个用户何时运行的估计值 我们可以期待请求得到满足

响应可以包含位置标头，以指示客户端需要在何处查询请求的状态

据我所知，没有浏览器使用202 Accepted实现任何特殊功能，因此您需要自己在客户端实现对202 Accepted的处理

一种可能的实现是，Location报头中的URI将是您试图创建的资源最终将进入的URI，并且它将在GET请求中返回404，直到处理完成

---

另一个更复杂的实现是，Location报头中的URI将是异步请求的进度资源的URI，它将返回一个200 OK的请求进度状态，当处理完成时，资源将返回一个201，其中包含所创建资源的最终位置。

我可能想得太像这里的前端了。我想我想在一些原型主干模型中自动处理非标准响应。但你可能是对的。从API的角度来看，它是一个200，具有不同的负载，用户应该处理它。@AndyNovocin，我可以看出你来自哪里。在某个时候我