blocks|key|235474|text|另一种选择：503+-+Service+Unavailable。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|235475|entityMap^0|6|P|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Another option: <code>503 - Service Unavailable</code>.

blocks|key|3111516|text|问题在服务器端:客户端发出了一个格式良好的请求，但服务器无法满足它。所以我倾向于使用“服务器错误”，5xx状态码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3111517|Quoth+(当前的RFC+7231标准，重点增加)：|offset|length|3111518|3111519|状态代码的5xx+(服务器错误)类指示服务器知道它的出错或无法执行请求的方法。除非响应HEAD请求，否则服务器应发送一个表示，其中包含错误情况的解释，以及它是临时还是永久条件。|blockquote|style|BOLD|3111520|3111521|3111522|备注|3111523|3111524|"erred++or++is+incapable+performing+the+request"：尽管它们的标题是“服务器错误”，但它们不仅仅适用于服务器错误或永久错误:这些代码适用于暂时不可用的资源，如您的。|unordered-list-item|3111525|3111526|在可用的代码中，我认为503,+"Service+Unavailable"是最合适的：|3111527|3111528|+503+(服务不可用)状态代码指示服务器当前由于临时过载或计划维护而无法处理请求，这可能会在一段延迟后得到缓解。服务器可能会发送一个Retry+After报头字段...建议客户端在重试请求之前等待适当的时间。|3111529|3111530|3111531|注意：|3111532|对于你的case.|3111533|"temporary过载来说，|3111534|“可能会在一些延迟后得到缓解”：对于你的情况来说，这并不是书生气十足的真实。但是，可以说，如果您的服务器速度快得多，当客户端发出请求时，批处理就已经完成了，因此这是一种“过载”：客户端请求资源的速度快于服务器使其available.|3111535|Retrying适合您的服务的速度，因此您的回复应该包含一个Retry-After值。您可以提供批处理下一次执行的预计完成时间或批处理的执行间隔作为值。|CODE|3111536|3111537|3111538|定义自己的5xx状态代码(例如，591)，尽管是permitted，但具有错误的语义：|3111539|3111540|客户端必须理解任何状态代码的类，并将无法识别的状态代码视为等同于该类的x00状态代码|3111541|3111542|3111543|客户端会将您自己的状态代码视为500,+"Internal+Server+Error"，这是不正确的。|3111544|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7231#section-6.6|1|https://www.rfc-editor.org/rfc/rfc7231#section-6.6.4|2|https://www.rfc-editor.org/rfc/rfc7231#section-6|3|https://www.rfc-editor.org/rfc/rfc7231#section-6.6.1^0|0|A|8|0|0|0|Q|C|27|2|0|0|0|0|0|7|4|0|0|B|Q|1|0|0|0|0|0|0|0|0|0|U|B|0|0|0|O|9|2|0|0|0|0|0|F|S|3|0^^$0|@$1|2|3|4|5|6|7|21|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|22|8|@]|9|@$D|23|E|24|1|25]]|A|$]]|$1|F|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|27|8|@$D|28|E|29|J|K]|$D|2A|E|2B|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2E|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|2G|8|@$D|2H|E|2I|J|K]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2K|8|@]|9|@$D|2L|E|2M|1|2N]]|A|$]]|$1|W|3|-4|5|6|7|2O|8|@]|9|@]|A|$]]|$1|X|3|Y|5|I|7|2P|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|2S|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|2T|8|@]|9|@]|A|$]]|$1|15|3|16|5|S|7|2U|8|@]|9|@]|A|$]]|$1|17|3|18|5|S|7|2V|8|@]|9|@]|A|$]]|$1|19|3|1A|5|S|7|2W|8|@$D|2X|E|2Y|J|1B]]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|30|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|31|8|@]|9|@$D|32|E|33|1|34]]|A|$]]|$1|1G|3|-4|5|6|7|35|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|I|7|36|8|@]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|38|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|39|8|@]|9|@$D|3A|E|3B|1|3C]]|A|$]]|$1|1N|3|-4|5|6|7|3D|8|@]|9|@]|A|$]]]|1O|$1P|$5|1Q|1R|1S|A|$1T|1U]]|1V|$5|1Q|1R|1S|A|$1T|1W]]|1X|$5|1Q|1R|1S|A|$1T|1Y]]|1Z|$5|1Q|1R|1S|A|$1T|20]]]]

The &quot;problem&quot;, such as it is, is on the server side: the client has made a well formed request, but the server can not satisfy it. So I'm inclined to a &quot;Server Error&quot;, 5xx status code.
Quoth <a href="https://www.rfc-editor.org/rfc/rfc7231#section-6.6" rel="nofollow noreferrer">RFC 7231</a> (the current HTTP standard, emphasis added):
<blockquote>
The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the
requested method. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent condition.
</blockquote>
Note
<ul>
<li>&quot;erred or is incapable of performing the request&quot;: despite their title of &quot;Server Error&quot;, they are not just for server errors.</li>
<li>&quot;temporary or permanent&quot;: these codes are suitable for temporarily unavailable resources, like yours.</li>
</ul>
Of the available codes, I'd say <a href="https://www.rfc-editor.org/rfc/rfc7231#section-6.6.4" rel="nofollow noreferrer">503, &quot;Service Unavailable&quot;</a> was the best fit:
<blockquote>
The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay. The server MAY send a Retry-After header field... to suggest an appropriate amount of time for the
client to wait before retrying the request.
</blockquote>
Note:
<ul>
<li>&quot;likely be alleviated after some delay&quot;: true for your case.</li>
<li>&quot;temporary overload&quot;: 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 &quot;overload&quot;: the client is asking for resources faster than the server can make them available.</li>
<li>Retrying is suitable for your service, so your reply ought to include a <code>Retry-After</code> 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.</li>
</ul>
Defining your own 5xx status code (591, for example), although <a href="https://www.rfc-editor.org/rfc/rfc7231#section-6" rel="nofollow noreferrer">permitted</a>, would have the wrong semantics:
<blockquote>
a client MUST
understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class
</blockquote>
Clients would treat your own status code as <a href="https://www.rfc-editor.org/rfc/rfc7231#section-6.6.1" rel="nofollow noreferrer">500, &quot;Internal Server Error&quot;</a>, which would not be right.

blocks|key|234430|text|由于您的资源尚未准备就绪，因此您可能知道它何时(大约)可用，以及客户端何时可以重试其请求。这意味着您可能想要利用Retry-After+header。此标头在503+(服务不可用)和3xx+(重定向)响应中有效，503(服务不可用)表示整个站点停止维护。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|234431|在我看来，带有Retry+After报头的302+(找到)将是最好的选择，但我不确定响应头的位置字段是否可以等于请求url。不管怎么说，这是循环重定向。|234432|entityMap|0|LINK|mutability|MUTABLE|url|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html^0|1K|I|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Since your resource is not ready, you probably know when (approximately) it will be available and when client may retry his request. This means you might want to utilize <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html">Retry-After header</a>. This header is valid with 503 (Service Unavailable), which means whole site is down for maintenance, and 3xx (Redirection) responses.

In my opinion 302 (Found) with Retry-After header would be the best option, but I am not sure if Location field of response header can be equal to request url. It's circular redirect, anyway.

blocks|key|231722|text|我建议使用202+-+Accepted。从documentation|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|231723|231724|已接受请求以进行处理，但处理尚未完成。..。它的目的是允许服务器接受某个其他进程的请求(可能是一个每天只运行一次的面向批处理的进程)|blockquote|231725|231726|entityMap|0|LINK|mutability|MUTABLE|url|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3^0|5|E|L|D|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|Z|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|L|$M|$5|N|O|P|E|$Q|R]]]]

I suggest <code>202 - Accepted</code>. From the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3">documentation</a>:

<blockquote>
 The request has been accepted for processing, but the processing has not been completed. [...] 
 Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day)
</blockquote>

blocks|key|231731|text|我不想返回404；，这是针对不存在的东西。，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|231732|。|blockquote|231733|231734|231735|URL并不对应于对某个东西的请求。|231736|http://server/thingyapi/thingyblob/1234|offset|length|style|CODE|231737|客户端正在请求一个不存在的thingyblob。如果它存在，你会把它给他们。|231738|404.|231739|entityMap^0|0|0|0|0|0|0|13|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@$K|10|L|11|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

<blockquote>
 I don't want to return 404; that's for thingies that do not exist.
</blockquote>

The URL doesn't correspond to a request for a thingy.

<code>http://server/thingyapi/thingyblob/1234</code>

The client is requesting a thingyblob, which doesn't exist. If it existed, you would give it to them.

404.

blocks|key|3111670|text|501+-未实施|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3111671|就像它听起来那样。一种尚未实现的功能，但意味着未来的可用性。|3111672|这是一个指向summary+of+5xx+errors的链接。|offset|length|3111673|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error^0|0|0|6|L|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

501 - Not Implemented

Exactly like how it sounds. A feature that is not yet implemented, but implies future availability.

Here is a link to a <a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error" rel="nofollow">summary of 5xx errors</a>.

blocks|key|2897551|text|409冲突|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2897552|指示由于请求中的冲突而无法处理请求，例如在多个更新的情况下发生编辑冲突。来源维基百科。|2897553|这可能是合适的。|2897554|如果你不能通过返回数据来满足请求，那么它就不是成功的。我认为202表明服务器已经将请求排队，它将在稍后完成请求。但在您的情况下，请求现在是对数据的请求，并且已经失败。如果您稍后重试，则是另一个请求。|2897555|我想你有冲突了..你想要数据..但它正在被编辑/更新。如果Thingy1234已经存在并且之前已经成功下载，但现在正在编辑过程中，在编辑发生时不可用，也会出现这种情况。|2897556|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

409 Conflict 

Indicates that the request could not be processed because of conflict in the request, such as an edit conflict in the case of multiple updates. [Source Wikipedia.]

This could be appropriate.

If you cant fulfill the request by returning the data - then its not a success. I think 202 suggests the server has queued the request and it will fulfill the request later. But in your case, the request is for data now and has failed. If you retry later it is a different request.

I think you have a conflict.. you want the data.. but its being edited / updated. This would also be the case if Thingy1234 already existed and had been successfully downloaded before, but now was in the process of being edited was was unavailable whilst the edit was taking place.

blocks|key|2897588|text|我认为423+-+Locked可以用于此目的：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2897589|2897590|+423+(已锁定)状态码表示方法的源或目标资源已锁定。此响应应包含适当的前置条件或后置条件代码，例如“lock-token-submitted”或“no-conflicting-lock”。|blockquote|2897591|2897592|entityMap|0|LINK|mutability|MUTABLE|url|http://www.restpatterns.org/HTTP_Status_Codes/423_-_Locked^0|3|C|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

I think that <a href="http://www.restpatterns.org/HTTP_Status_Codes/423_-_Locked" rel="noreferrer">423 - Locked</a> can be used for this purpose:

<blockquote>
 The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
</blockquote>

I'm developing a RESTful API in which <code>http://server/thingyapi/thingyblob/1234</code> returns the file (aka "blob") associated with thingy #1234 to download. But it may be that the request is made at a time the file does not exist in the server but most definitely will be available at a later time. There's a batch process in the server that generates all the blobs for all the thingies. Thingy 1234 already exists and its data, other than the blob, is already available. The server hasn't got to generating thingy 1234's blob yet.

I don't want to return 404; that's for thingies that do not exist. This is a thingy that exists, but its blob hasn't been generated yet. Kinda like a YouTube video that's "processing." I don't think redirection codes would be proper either; there's no "other" URL to try.

What's the correct HTTP status code to return in such a case?

How do I choose a HTTP status code in REST API for "Not Ready Yet, Try Again Later"?

我正在开发一个blob应用程序接口，其中http://server/thingyapi/thingyblob/1234返回与要下载的东西#1234相关的文件(也称为“RESTful”)。但可能是在文件不存在于服务器中的时候发出请求，但最确定的是将在稍后的时间可用。在服务器中有一个批处理过程，它为所有的东西生成所有的斑点...

问如何在REST API中为“尚未就绪，稍后再试”选择HTTP状态代码？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在REST API中为“尚未就绪，稍后再试”选择HTTP状态代码？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在REST API中为“尚未就绪，稍后再试”选择HTTP状态代码？
EN