如何在REST API中为“尚未就绪，请稍后再试”选择HTTP状态代码？[关闭]

我正在开发RESTful API，在其中http://server/thingyapi/thingyblob/1234返回与要下载的东西＃1234相关的文件（又称“ blob”）。但是可能是在服务器中不存在该文件时发出请求，但肯定以后会提供该文件。服务器中有一个批处理过程，可为所有事物生成所有blob。Thingy 1234已经存在，并且除blob之外的其他数据已经可用。服务器还没有生成东西1234的斑点。

我不想返回404；那是针对不存在的事物。这是一个存在的问题，但尚未生成它的斑点。Kinda喜欢YouTube影片中的「处理中」。我也不认为重定向代码是合适的。没有尝试使用的“其他” URL。

在这种情况下返回的正确HTTP状态代码是什么？

我建议202 - Accepted。从文档中：

该请求已被接受进行处理，但是处理尚未完成。[...]其目的是允许服务器接受对其他进程的请求（也许是每天仅运行一次的面向批处理的进程）

这样的“问题”在服务器端：客户端提出了格式正确的请求，但服务器无法满足。因此，我倾向于使用5xx状态代码的“服务器错误”。

Quoth RFC 7231（当前的HTTP标准，已添加重点）：

状态代码的5xx（服务器错误）类表示服务器知道服务器已错误或无法执行所请求的方法。除响应HEAD请求外，服务器应发送一个包含错误情况说明以及它是暂时还是永久情况的说明。

注意

• “错误或无法执行请求”：尽管标题为“服务器错误”，但它们不仅仅用于服务器错误。
• “ 临时或永久”：这些代码适用于像您这样的暂时不可用的资源。

在可用代码中，我会说503，“服务不可用”是最合适的代码：

503（服务不可用）状态代码表示服务器当前由于暂时的过载或计划的维护而无法处理该请求，这可能会在某些延迟后得到缓解。服务器可以发送一个Retry-After头域...来建议一个适当的时间，以便客户端在重试请求之前等待。

注意：

• “经过一段时间的延迟后可能会得到缓解”：适用于您的情况。
• “临时超载”：在您的情况下不是很真实。但是，可以争辩的是，如果您的服务器要快得多，那么当客户端发出请求时批处理就已经完成了，因此这是一种“超载”：客户端请求资源的速度超过了服务器的处理能力他们可用。
• 重试适合您的服务，因此您的回复应包含一个Retry-After值。您可以提供下一次执行批处理的估计完成时间或批处理的执行间隔作为值。

定义自己的5xx状态代码（例如591）（虽然允许）将具有错误的语义：

客户端必须理解任何状态代码的类别（如第一位数字所示），并将无法识别的状态代码视为等同于该类别的x00状态代码

客户端会将您自己的状态代码视为500，“ Internal Server Error”，这是不正确的。

我认为423-Locked可用于此目的：

423（锁定）状态代码表示方法的源或目标资源已锁定。该响应应该包含适当的前提条件或后置条件代码，例如“锁令牌提交”或“无冲突锁”。

我不想返回404；那是针对不存在的事物。

该网址与对一件东西的请求不符。

http://server/thingyapi/thingyblob/1234

客户端请求的内容不存在。如果存在，您可以将其交给他们。

404。

另一种选择：503 - Service Unavailable。

由于您的资源尚未准备好，您可能知道（何时）该资源何时可用以及客户端何时可以重试其请求。这意味着您可能想利用Retry-After header。该标头与503（服务不可用）一起有效，这意味着整个站点都将停止维护，并且3xx（重定向）响应。

我认为带有Retry-After标头的302（找到）是最好的选择，但是我不确定响应标头的Location字段是否可以等于请求url。无论如何，这是循环重定向。

409冲突

指示由于请求中的冲突而无法处理该请求，例如在多次更新的情况下发生编辑冲突。[资料来源Wikipedia。]

这可能是适当的。

如果您无法通过返回数据来满足请求-那么它就不会成功。我认为202建议服务器已将请求排队，并且它将在以后满足该请求。但是对于您而言，该请求现在是数据请求，但已失败。如果稍后重试，则是另一个请求。

我认为您有冲突..您想要数据..但正在编辑/更新。如果Thingy1234已经存在并且之前已成功下载，但现在正在进行编辑，则在进行编辑时将不可用，情况也会如此。

501-未实施

就像听起来一样。尚未实现的功能，但意味着将来的可用性。

这是5xx错误摘要的链接。