blocks|key|2904787|text|对于业务规则，您应该使用400。如果订单未被接受，则不要返回2xx。HTTP是一个应用程序协议，永远不要忘记这一点。如果您返回2xx，则客户端可以假定订单已被接受，而不管您在正文中发送的任何信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2904788|2904789|来自RESTful+Web+Services+Cookbook|offset|length|2904790|​|2904791|2904792|一些web服务常犯的一个错误是返回一个反映成功的状态代码(状态代码从200到206以及从300到307)，但包括描述错误条件的消息体。这样做可以防止支持HTTP的软件检测错误。例如，缓存会将其存储为成功的响应，并将其提供给后续客户端，即使客户端可能能够发出成功的请求。|blockquote|2904793|2904794|2904795|我将让您在4xx和5xx之间做出选择，但您应该使用错误状态代码。|2904796|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0596801688^0|0|0|2|T|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|10|8|@]|9|@$E|11|F|12|1|13]]|A|$]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|16|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

You should use 400 for business rules. Don't return 2xx if the order was not accepted. HTTP is an application protocol, never forget that. If you return 2xx the client can assume the order was accepted, regardless of any information you send in the body.
<hr/>
From <a href="https://rads.stackoverflow.com/amzn/click/com/0596801688" rel="noreferrer" rel="nofollow noreferrer">RESTful Web Services Cookbook</a>:

<blockquote>
 One common mistake that some web services make is to return a status
 code that reflects success (status codes from 200 to 206 and from 300
 to 307) but include a message body that describes an error condition.
 Doing this prevents HTTP-aware software from detecting errors. For
 example, a cache will store it as successful response and serve it to
 subsequent clients even when clients may be able to make a successful
 request.
</blockquote>

I'll leave it to you to decide between 4xx and 5xx, but you should use an error status code.

blocks|key|3119179|text|如果客户端可以修改请求以避免错误，则应使用4xx表示客户端错误。对于客户端无法真正解决的服务器错误，请使用5xx。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3119180|产品售罄将是服务器错误。客户端不能以某种方式修改请求来绕过错误。您可以切换到其他产品，但这不是一个新的要求吗？|3119181|达到用户最大订单限制也是一个服务器错误。客户端不能做任何事情来解决这个错误。|3119182|信用卡交易失败将是一个客户端错误。客户可以使用不同的付款方式或信用卡号码重新提交请求，以解决此错误。|3119183|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You should use 4xx for a client error if the client can modify the request to get around the error. Use a 5xx for a server error that the client can't really work around.

Product sold out would be a server error. The client can't modify the request in some fashion to get around the error. You could switch to another product but wouldn't that be a new request?

User maximum order limit reached is also a server error. Nothing the client can do to work around that error.

Credit card transaction failure would be a client error. The client could resubmit the request with a different payment method or credit card number to work around the error.

blocks|key|235433|text|我不认为400可以用于所有的业务场景。它可用于基本数据输入验证。除此之外，我们可能很难将其他业务逻辑放入此错误代码中。由此处理的错误主要是设计时错误，开发人员可能会在客户端的编码过程中遇到这些错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|235434|假设所有参数都是正确的，并将用户帐号传递给请求。|235435|因此，请求现在不再是一个坏请求，服务器能够接受该请求。但现在它拒绝根据新的可用信息完成请求，这是-帐户没有足够的余额。|235436|我建议我们应该在这些场景中使用带有适当错误消息的403。|235437|其他可能的错误代码可能是409冲突。但这是在资源处于一致状态的情况下使用的。|235438|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|$]]

I do'nt think 400 can be used for all the business scenario. It can be used for basic data input validation. Beyond that we might have hard to time fit other business logic into this error code. The error handled by this are mostly design time errors which developer will encounter possibly during the coding of the client. 

Let's say all parameters are correct and let's say we are passing user account number into the request.

So request is now no longer a bad request, the server is able to accept the request. But now it is refusing to fulling the request based on new information available which is - account does not have sufficient balance.

I would suggest we should use 403 with appropriate error message in those scenarios. 

Other possible error code could be 409 conflict. But that is used in scenarios where the resource is in in consistent state.

blocks|key|3119229|text|我知道这个问题很老，但我今天也提出了同样的问题。如果我的用户用完了配额，我的REST+API应该返回什么状态代码？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3119230|我倾向于使用402+Payment+Required|offset|length|style|CODE|3119231|根据Wikipedia的说法|3119232|保留供将来使用的|3119233|。最初的意图是，这种代码可能会被用作某种形式的数字现金或微支付方案的一部分，但这并没有发生，而且这种代码通常不会使用。如果某个特定的开发者超过了每日请求的限制，Google+Developers+API就会使用此状态。|blockquote|3119234|3119235|3119236|甚至还有they+do|3119237|3119238|+PAYMENT_REQUIRED+(402)|3119239|3119240|3119241|3119242|已达到开发人员设置的每日预算限制。|unordered-list-item|3119243|请求的操作需要的资源超出配额允许的范围。需要付款才能完成operation.|3119244|The请求的操作需要经过身份验证的用户进行某种付款。|3119245|3119246|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#402|1|https://developers.google.com/doubleclick-search/v2/standard-error-responses#PAYMENT_REQUIRED^0|0|6|K|0|2|9|0|0|0|0|0|0|4|7|1|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1K|8|@]|9|@$D|1L|E|1M|1|1N]]|A|$]]|$1|J|3|K|5|6|7|1O|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1P|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1S|8|@]|9|@$D|1T|E|1U|1|1V]]|A|$]]|$1|S|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|T|3|U|5|N|7|1X|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|20|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|21|8|@]|9|@]|A|$]]|$1|11|3|12|5|10|7|22|8|@]|9|@]|A|$]]|$1|13|3|14|5|10|7|23|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|25|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]|1E|$5|19|1A|1B|A|$1C|1F]]]]

I know this question is old, but I came up with the very same question today. If my user runs out of credits, what status code should my REST API return?
I tend to lean towards <code>402 Payment Required</code>:
According to <a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#402" rel="noreferrer">Wikipedia</a>:
<blockquote>
Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code is not usually used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.
</blockquote>
And indeed <a href="https://developers.google.com/doubleclick-search/v2/standard-error-responses#PAYMENT_REQUIRED" rel="noreferrer">they do</a>:
<blockquote>
PAYMENT_REQUIRED (402)
<ul>
<li>A daily budget limit set by the developer has been reached.</li>
<li>The requested operation requires more resources than the quota allows. Payment is required to complete the operation.</li>
<li>The requested operation requires some kind of payment from the authenticated user.</li>
</ul>
</blockquote>

blocks|key|238038|text|错误类型：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|238039|4××+Client+Error|code-block|syntax|javascript|238040|错误码：|238041|422+Unprocessable+Entity|238042|服务器了解请求实体的内容类型(因此，415不支持的媒体类型状态代码是不适当的)，并且请求实体的语法是正确的(因此，400错误的请求状态代码是不适当的)，但是无法处理所包含的指令。|238043|例如，如果XML请求正文包含格式正确(即语法正确)但语义错误的XML指令，则可能出现此错误情况。|238044|https://httpstatuses.com/422|offset|length|238045|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|S|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|11|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|15|8|@]|9|@$Q|16|R|17|1|18]]|A|$]]|$1|S|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|P]]]]

Error type:

<pre><code>4×× Client Error
</code></pre>

Error code:

<pre><code>422 Unprocessable Entity
</code></pre>

The server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions.

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

<a href="https://httpstatuses.com/422" rel="noreferrer">https://httpstatuses.com/422</a>

blocks|key|2905034|text|我用406+Not+Acceptable。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2905035|下面是一个4xx列表：|2905036|const+HTTP_BAD_REQUEST+=+400;
const+HTTP_UNAUTHORIZED+=+401;
const+HTTP_PAYMENT_REQUIRED+=+402;
const+HTTP_FORBIDDEN+=+403;
const+HTTP_NOT_FOUND+=+404;
const+HTTP_METHOD_NOT_ALLOWED+=+405;
const+HTTP_NOT_ACCEPTABLE+=+406;
const+HTTP_PROXY_AUTHENTICATION_REQUIRED+=+407;
const+HTTP_REQUEST_TIMEOUT+=+408;
const+HTTP_CONFLICT+=+409;
const+HTTP_GONE+=+410;
const+HTTP_LENGTH_REQUIRED+=+411;
const+HTTP_PRECONDITION_FAILED+=+412;
const+HTTP_REQUEST_ENTITY_TOO_LARGE+=+413;
const+HTTP_REQUEST_URI_TOO_LONG+=+414;
const+HTTP_UNSUPPORTED_MEDIA_TYPE+=+415;
const+HTTP_REQUESTED_RANGE_NOT_SATISFIABLE+=+416;
const+HTTP_EXPECTATION_FAILED+=+417;
const+HTTP_I_AM_A_TEAPOT+=+418;+++++++++++++++++++++++++++++++++++++++++++++++//+RFC2324
const+HTTP_MISDIRECTED_REQUEST+=+421;+++++++++++++++++++++++++++++++++++++++++//+RFC7540
const+HTTP_UNPROCESSABLE_ENTITY+=+422;++++++++++++++++++++++++++++++++++++++++//+RFC4918
const+HTTP_LOCKED+=+423;++++++++++++++++++++++++++++++++++++++++++++++++++++++//+RFC4918
const+HTTP_FAILED_DEPENDENCY+=+424;+++++++++++++++++++++++++++++++++++++++++++//+RFC4918
const+HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL+=+425;+++//+RFC2817
const+HTTP_UPGRADE_REQUIRED+=+426;++++++++++++++++++++++++++++++++++++++++++++//+RFC2817
const+HTTP_PRECONDITION_REQUIRED+=+428;+++++++++++++++++++++++++++++++++++++++//+RFC6585
const+HTTP_TOO_MANY_REQUESTS+=+429;+++++++++++++++++++++++++++++++++++++++++++//+RFC6585|code-block|syntax|javascript|2905037|entityMap^0|6|E|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|R|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|S|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

I go with 406 <code>Not Acceptable</code>. 

Here's a 4xx list:

<pre><code>const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418; // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421; // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422; // RFC4918
const HTTP_LOCKED = 423; // RFC4918
const HTTP_FAILED_DEPENDENCY = 424; // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425; // RFC2817
const HTTP_UPGRADE_REQUIRED = 426; // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428; // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429; // RFC6585
</code></pre>

blocks|key|240976|text|那424+Failed+Dependency呢？规范将其描述为：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|240977|240978|无法在资源上执行该方法，因为请求的操作依赖于另一个操作，而该操作失败。|blockquote|240979|240980|240981|但也有this+definition|240982|240983|状态码424是在WebDAV标准中定义的，用于客户端需要更改其正在执行的操作的情况-服务器在这里没有遇到任何问题。|240984|240985|240986|您可以告诉客户端(或假装)，您有应该创建订单的内部操作，并扣除余额，其中一个操作失败了，尽管是完全合理的原因，这就是请求失败的原因。|240987|据我所知，“行动”是一个相当宽泛的术语，可以在各种情况下使用，包括库存不足、信用不足或仓库聚会之夜。|240988|240989|另一个选项可能是422+Unprocessable+Entity|240990|240991|服务器了解请求实体的内容类型(因此，415不支持的媒体类型状态代码是不合适的)，并且请求实体的语法是正确的(因此，400错误的请求状态代码是不合适的)，但是无法处理所包含的指令。|240992|240993|例如，如果XML请求正文包含格式正确(即语法正确)但语义错误的XML指令，则可能出现此错误情况。|240994|240995|试图请求脱销的商品，或者当你没有足够的信用时，在语义层面上可能被认为是错误的。|240996|MozDev+says这表明客户端有一个错误，特别是:客户端不应该在没有修改的情况下重复此请求。|240997|当输入验证失败时，环回4+uses+422。|240998|240999|可以说，库存不足或仓库聚会之夜可以被视为临时状态，因此可以稍后重试该请求。这种情况可以通过503+Service+Unavailable来表示|241000|241001|由于临时过载或计划维护，服务器当前无法处理请求，延迟一段时间后可能会得到缓解。|241002|241003|服务器可能会发送一个Retry+After标头字段，建议客户端在重试请求之前等待适当的时间。|241004|entityMap|0|LINK|mutability|MUTABLE|url|https://httpstatuses.com/424|1|https://stackoverflow.com/a/18711343|2|https://httpstatuses.com/422|3|https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422|4|https://github.com/strongloop/loopback/issues/935#issuecomment-69964855|5|https://httpstatuses.com/503^0|1|L|1|L|0|0|0|0|0|0|3|F|1|0|0|0|0|0|0|0|0|8|O|8|O|2|0|0|0|0|0|0|0|7|4|3|0|D|4|4|0|0|19|N|19|N|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|23|8|@$9|24|A|25|B|C]]|D|@$9|26|A|27|1|28]]|E|$]]|$1|F|3|-4|5|6|7|29|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|2A|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|2B|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|2C|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|2D|8|@]|D|@$9|2E|A|2F|1|2G]]|E|$]]|$1|N|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]|$1|O|3|P|5|I|7|2I|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|2K|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|2L|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|2M|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|2N|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|2O|8|@$9|2P|A|2Q|B|C]]|D|@$9|2R|A|2S|1|2T]]|E|$]]|$1|Z|3|-4|5|6|7|2U|8|@]|D|@]|E|$]]|$1|10|3|11|5|I|7|2V|8|@]|D|@]|E|$]]|$1|12|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|2X|8|@]|D|@]|E|$]]|$1|15|3|-4|5|6|7|2Y|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|30|8|@]|D|@$9|31|A|32|1|33]]|E|$]]|$1|1A|3|1B|5|6|7|34|8|@]|D|@$9|35|A|36|1|37]]|E|$]]|$1|1C|3|-4|5|6|7|38|8|@]|D|@]|E|$]]|$1|1D|3|1E|5|6|7|39|8|@$9|3A|A|3B|B|C]]|D|@$9|3C|A|3D|1|3E]]|E|$]]|$1|1F|3|-4|5|6|7|3F|8|@]|D|@]|E|$]]|$1|1G|3|1H|5|I|7|3G|8|@]|D|@]|E|$]]|$1|1I|3|-4|5|6|7|3H|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|6|7|3I|8|@]|D|@]|E|$]]|$1|1L|3|-4|5|6|7|3J|8|@]|D|@]|E|$]]]|1M|$1N|$5|1O|1P|1Q|E|$1R|1S]]|1T|$5|1O|1P|1Q|E|$1R|1U]]|1V|$5|1O|1P|1Q|E|$1R|1W]]|1X|$5|1O|1P|1Q|E|$1R|1Y]]|1Z|$5|1O|1P|1Q|E|$1R|20]]|21|$5|1O|1P|1Q|E|$1R|22]]]]

How about <a href="https://httpstatuses.com/424" rel="nofollow noreferrer"><code>424 Failed Dependency</code></a>? The spec describes it as:
<blockquote>
The method could not be performed on the resource because the requested action depended on another action and that action failed.
</blockquote>
But there is also <a href="https://stackoverflow.com/a/18711343">this definition</a>:
<blockquote>
Status code 424 is defined in the WebDAV standard and is for a case where the client needs to change what it is doing - the server isn't experiencing any problem here.
</blockquote>
You can tell the client (or pretend) that you have internal actions which are supposed to create the order, and deduct the balance, and that one of those actions failed, albeit for perfectly valid reasons, and that's why the request failed.
As far as I can see, &quot;action&quot; is quite a broad term, and can be used in a variety of situations, including insufficient stock, insufficient credit, or warehouse party night.
<hr />
Another option might be <a href="https://httpstatuses.com/422" rel="nofollow noreferrer"><code>422 Unprocessable Entity</code></a>:
<blockquote>
The server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions.
For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
</blockquote>
Trying to request an item which is out of stock, or when you have insufficient credit, might be considered a mistake at the semantic level.
MozDev <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422" rel="nofollow noreferrer">says</a> this indicates a mistake on the client side, specifically: The client should not repeat this request without modification.
Loopback 4 <a href="https://github.com/strongloop/loopback/issues/935#issuecomment-69964855" rel="nofollow noreferrer">uses</a> 422 when input validation fails.
<hr />
Arguably, insufficient stock or warehouse party night could be considered temporary states, so the request could be retried again later. That situation can be indicated by <a href="https://httpstatuses.com/503" rel="nofollow noreferrer"><code>503 Service Unavailable</code></a>
<blockquote>
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>

I'm creating a RESTful API that will process a number of user interactions, including placing orders using stored credit cards.

In the case of a successful order, I'm returning a 200 OK, and in the case where the order request is malformed or invalid I'm returning a 400 Bad Request. But what should I return if there is a problem during the actual processing of the order?

<ol>
<li>Client POSTS order to server for a user resource. If user does not exist, 404 Not Found is returned.</li>
<li>Order format and information is validated. If not valid, 400 Bad Request is returned.</li>
<li>Order is processed. If the order is successful, a 201 Created is returned for the order. If an unexpected error is encountered, a 500 Server Error is returned.</li>
</ol>

The last step is the problem - what do I return if the order doesn't complete for any other reason? Possible scenarios could include:

<ul>
<li>Product is sold out</li>
<li>User maximum order limit reached</li>
<li>Credit card transaction failure (insufficient funds, etc.)</li>
</ul>

This doesn't seem like it would be appropriate for either a 400 or 500. If anything I could see it as a 400 if there's no better code - the request was invalid according to the business rules. It just doesn't seem accurate.

Edit: Also found <a href="https://stackoverflow.com/questions/2190945/what-http-response-code-for-rest-service-on-put-method-when-domain-rules-invalid">this existing discussion</a> of the same topic. All of the answers there seem to point to using status codes for this type of violation, with some discussion between using 400, 409, or the 422 extension.

What is the appropriate HTTP status code response for a general unsuccessful request (not an error)?

我正在创建一个RESTful应用程序接口，它将处理许多用户交互，包括使用存储的信用卡下单。在订单成功的情况下，我返回200OK，如果订单请求格式错误或无效，我将返回400Bad请求。但是，如果在实际处理订单的过程中出现问题，我应该返回什么？客户端将用户资源的订单发送到服务器。如果用户不存在，则404Not Found为...

问对于一般不成功的请求(不是错误)，适当的HTTP状态码响应是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于一般不成功的请求(不是错误)，适当的HTTP状态码响应是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于一般不成功的请求(不是错误)，适当的HTTP状态码响应是什么？
EN