这是我的第一个问题，请善待。
在构建API时，您会遇到一个需要一段时间才能处理的请求。较长的API进程可能导致请求超时。
（在我的情况下是一种PUT或POST方法，涉及上传到第三方eBay并与之通信。这会创建或更新列表并返回响应信息。）
为了避免超时，我决定向用户发送一个响应，其中包含一个可以轮询最终结果的URL。 （这个想法来自SO搜索，我使用this method返回HTTP响应，同时继续处理和this idea设计概念：POST / PUT到一个地址，然后在另一个地址GET。）
我希望这个'forked'处理对于API请求是可选的，以便将来可以打开或关闭它。 这意味着API的用户可能只是收到他们想要的结果，或者可能获得一个不同的URL，最终可以从中获取结果。似乎HTTP响应代码是处理此问题的最佳方式。当您的结果按预期返回时返回200，当用户稍后将GET更新到其他URL时返回其他内容。
因此，选择正确的HTTP响应代码比我希望的更加微妙（我想我可以使用自定义代码，314就像pi一样容易）。似乎应该使用3xx，因为这是一个重定向，但是当我使用303时，浏览器立即处理重定向并且实际上仍然需要相同的长度（使用chrome中的POSTMAN）。使用307是不合适的，因为我希望下一个请求是GET而不是PUT或POST。自定义3xx仍然由浏览器自动重定向。当我使用'305 Use Proxy'时，一切正常。 API的用户立即获得响应，他们可以选择在他们认为合适的情况下处理它。
所以这就是问题：依赖此浏览器行为来使用代理是否安全（允许用户处理下一个呼叫）？如果不是最好的替代代码是什么？
对this question的回复意味着305未实施且可能已被弃用。
305的W3C段落说
必须通过Location字段提供的代理访问所请求的资源。 Location字段提供代理的URI。 收件人应通过代理重复此单个请求。 305响应必须仅由源服务器生成。
我认为这意味着正确的行为是委托收件人重复我想要的请求。
This response说：“我希望你不要试图产生305响应。”
我很高兴305以这种方式工作，所以我可以给你你的答案，或者让你决定何时在它可能准备好之后轮询其他网址以获得你的答案。如果我可以在不久的将来依赖这种行为，那么这意味着不必乱用websockets或排队长任务或网关超时。我担心浏览器会做出我想要的巧合而非设计，并且可能在将来305被删除或浏览器像其他3xx一样自动进行重定向。我宁愿不使用4xx，因为它不是错误，但我可以谈论它。
答案 0 :(得分：1)
从它的外观来看，305与你想要做的事情不符。通过代理重复请求不同于从其他位置请求资源或轮询URL。
也许只返回一个JSON对象，其中包含指向需要轮询的URL的链接并记录该行为。没有人编写神奇地处理HTTP代码的API客户端（除了显而易见的404,200等），所以如果你需要比普通重定向更复杂的东西，你总是需要记录它。
答案 1 :(得分：1)
这正是“202 Accepted”状态代码的用例：
10.2.3 202接受
请求已被接受处理，但处理已完成 尚未完成。该请求最终可能会或可能不会被采取行动 因为它可能在处理实际发生时被禁止。 没有从异步中重新发送状态代码的工具 这样的操作。
202回复是故意不承诺的。其目的是为了 允许服务器接受某个其他进程的请求（也许是 没有的批处理过程，每天只运行一次 要求用户代理与服务器的连接一直持续到 这个过程完成了。该实体返回此响应 应该包括请求的当前状态和指示 指向状态监视器的指针或用户何时估计 可以期待请求得到满足。
响应可以包含Location标头，以指示客户端需要查询请求状态的位置。
据我所知，没有任何浏览器使用202 Accepted实现任何特殊功能，因此您需要自己在客户端实现202 Accepted的处理。
一种可能的实现是，Location头中的URI将是您尝试创建的资源最终会进入的URI，并且它将在GET请求中返回404，直到处理完成。
另一个更复杂的实现是Location头中的URI将是异步请求的进度资源的URI，并且它将返回200 OK以及请求的进度状态，并且当处理完成时，资源将返回201 Created，其中包含已创建资源的最终位置。