哪个HTTP状态代码表示“尚未准备好，稍后再试”?

我正在开发一个RESTful API，其中http://server/thingyapi/thingyblob/1234返回与项目#1234相关联的文件(又名“blob")来下载。但是可以在生成文件之前提出请求。它肯定将将在以后的时间可用。

服务器中有一个批处理进程生成所有的blob。Item 1234已经存在，它的数据(除了blob)已经可用。服务器还没有生成1234的blob。

我不想返回404;那是指不存在的事物。它会存在，但还没有生成。有点像YouTube上的“处理”视频。我也不认为重定向代码是合适的;没有“其他”;URL尝试。

在这种情况下，要返回的正确HTTP状态码是什么?

85772 次浏览
小开

另一个选项:503 - Service Unavailable。

小开

问题是在服务器端:客户端提出了一个格式良好的请求，但是服务器不能满足它。所以我倾向于一个“服务器错误”，5xx状态代码。

Quoth RFC 7231(当前的HTTP标准，强调添加):

状态码的5xx (Server Error)类表示服务器错误 是否知道它已错误或无法执行 请求方法> < /强。除非响应HEAD请求，否则 服务器应该发送一个包含解释的表示

.错误情况，以及它是否是一个临时或永久条件

请注意

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

在可用的代码中，我认为503，“服务不可用”;是最合适的:

状态码503 (Service Unavailable)表示服务器不可用 由于临时过载，当前无法处理请求 或者定期维护，这可能会在一段时间后缓解 延迟。服务器可以发送一个Retry-After报头字段…建议适当的时间

.客户端等待重试请求

注意:

  • “延迟一段时间后可能会减轻”:对你的情况是正确的。
  • “暂时超载”:从学究角度来说，你的情况并不正确。但是，可以说，如果你的服务器快得多，批处理在客户端发出请求时就已经完成了，所以它是是一种“过载”:客户端请求资源的速度比服务器提供资源的速度快。
  • 重试适合于您的服务，因此您的回复应该包括Retry-After值。您可以提供批处理流程下一次执行的估计完成时间，或者批处理流程的执行间隔作为值。

定义你自己的5xx状态码(例如，591)，尽管允许，会有错误的语义:

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

客户端会将您自己的状态代码视为500，“内部服务器错误”;，这是不对的。

小开

由于您的资源还没有准备好，您可能知道它(大约)什么时候可用，什么时候客户可能会重试他的请求。这意味着你可能想要利用Retry-After头。此报头在503(服务不可用)下有效，这意味着整个站点正在进行维护，并响应3xx(重定向)。

在我看来，302(发现)与Retry-After报头将是最好的选择，但我不确定响应报头的位置字段是否可以等于请求url。这是循环重定向。

小开
最佳答案

我建议202 - Accepted。从文档:

请求已被接受处理，但处理尚未完成。[…] 它的目的是允许服务器接受对其他进程(可能是每天只运行一次的面向批处理的进程)的请求

小开

我不想返回404;那是指不存在的东西。

URL不对应于某个东西的请求。

http://server/thingyapi/thingyblob/1234

客户端正在请求一个thingyblob，但它并不存在。如果真有，你会给他们的。

404.

小开

501 -未实施

就像听起来一样。一个尚未实现，但暗示将来可用的特性。

这里有一个指向5xx个错误的总结的链接。

小开

409年冲突

指示由于请求中的冲突而无法处理请求，例如在多次更新的情况下发生编辑冲突。(维基百科来源。)

这可能是合适的。

如果你不能通过返回数据来满足请求-那么它不是一个成功。我认为202表明服务器已经排队请求，它将在以后完成请求。但在您的情况下，请求现在是数据，并且失败了。如果稍后重试，则是不同的请求。

我认为你有矛盾。你想要数据。但是它正在被编辑/更新。如果Thingy1234已经存在，并且之前已经成功下载，但现在处于编辑过程中，在编辑发生时不可用，也会出现这种情况。

小开

我认为423 -锁定可以用于此目的:

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


提交答案