我正在开发一个RESTful API，其中http://server/thingyapi/thingyblob/1234返回与项目#1234相关联的文件(又名“blob”)以下载。但是可以在生成文件之前提出请求。它肯定会在以后的时间可用。
服务器中有一个批处理进程生成所有的blob。Item 1234已经存在，它的数据(除了blob)已经可用。服务器还没有生成1234的blob。
我不想返回404;那是指不存在的事物。它会存在，但还没有生成。有点像YouTube上的“处理”视频。我也不认为重定向代码是合适的;没有“其他”URL可以尝试。
在这种情况下，要返回的正确HTTP状态码是什么?
当前回答
另一个选项:503 -服务不可用。
其他回答
501 -未实施
就像听起来一样。一个尚未实现，但暗示将来可用的特性。
这里有一个链接到5xx个错误的摘要。
“问题”是在服务器端:客户端提出了一个格式良好的请求，但服务器不能满足它。所以我倾向于“服务器错误”，5xx状态码。
Quoth RFC 7231(当前的HTTP标准，强调添加):
状态码的5xx (Server Error)类表示服务器 是否意识到它已经错误或不能执行 请求的方法。除非响应HEAD请求，否则 服务器应该发送一个包含解释的表示 错误的情况，以及它是暂时的还是永久的情况。
Note
“错误或无法执行请求”:尽管它们的标题是“服务器错误”，但它们不仅仅是用于服务器错误的。 “临时或永久”:这些代码适用于暂时不可用的资源，比如您的资源。
在可用的代码中，我认为503，“服务不可用”是最合适的:
状态码503(服务不可用)表示服务器 由于临时过载，当前无法处理请求 或者定期维护，这可能会在一段时间后缓解 延迟。服务器可以发送一个Retry-After报头字段…建议适当的时间 客户端等待重试请求。
注意:
"likely be alleviated after some delay": true for your case. "temporary overload": not pedantically true for your case. But, it could be argued, were your server much faster, the batch processing would have already been done when the client made the request, so it is a kind of "overload": the client is asking for resources faster than the server can make them available. Retrying is suitable for your service, so your reply ought to include a Retry-After value. You could provide as the value the estimated completion time of the next execution of the batch process, or the execution interval of the batch process.
定义你自己的5xx状态码(例如591)，虽然是允许的，但是会有错误的语义:
客户必须 理解任何状态代码的类，如第一个所示 数字，并将未被识别的状态代码视为等同于 该类的x00状态码
客户端会将您自己的状态代码视为500，即“内部服务器错误”，这是不对的。
我建议202 -接受。从文档中可以看到:
请求已接受处理，但处理尚未完成。[…] 它的目的是允许服务器接受对其他进程(可能是每天只运行一次的面向批处理的进程)的请求。
我认为423 - Locked可以用于这个目的:
423(锁定)状态码表示方法的源资源或目标资源是锁定的。此响应应包含适当的前置条件或后置条件代码，例如“锁令牌已提交”或“无冲突锁”。
另一个选项:503 -服务不可用。
