일반적인 실패한 요청 (오류 아님)에 대한 적절한 HTTP 상태 코드 응답은 무엇입니까?

일반적인 실패한 요청 (오류 아님)에 대한 적절한 HTTP 상태 코드 응답은 무엇입니까?

---

저장된 신용 카드를 사용하여 주문하는 것을 포함하여 여러 사용자 상호 작용을 처리하는 RESTful API를 만들고 있습니다.

성공적인 주문의 경우 200 OK를 반환하고 주문 요청이 잘못되었거나 잘못된 경우 400 Bad Request를 반환합니다. 그러나 실제 주문 처리 중에 문제가 발생하면 무엇을 반품해야합니까?

1. 클라이언트는 사용자 리소스에 대해 서버에 주문을 게시합니다. 사용자가 없으면 404 Not Found가 반환됩니다.
2. 주문 형식 및 정보가 확인되었습니다. 유효하지 않은 경우 400 Bad Request가 반환됩니다.
3. 주문이 처리됩니다. 주문이 성공하면 주문에 대해 201 Created가 반환됩니다. 예기치 않은 오류가 발생하면 500 서버 오류가 반환됩니다.

마지막 단계는 문제입니다. 다른 이유로 주문이 완료되지 않으면 무엇을 반품해야합니까? 가능한 시나리오는 다음과 같습니다.

• 상품이 매진되었습니다
• 사용자 최대 주문 한도에 도달했습니다.
• 신용 카드 거래 실패 (잔액 부족 등)

이것은 400 또는 500에 적합하지 않은 것 같습니다. 더 나은 코드가 없으면 400으로 볼 수있는 것이 있으면 비즈니스 규칙에 따라 요청이 유효하지 않습니다. 정확하지 않은 것 같습니다.

편집 : 동일한 주제에 대한 기존 토론 도 발견 했습니다 . 모든 답변은 이러한 유형의 위반에 대해 상태 코드를 사용하는 것으로 보이는데, 400, 409 또는 422 확장 사용 사이에 약간의 논의가 있습니다.

---

비즈니스 규칙에는 400을 사용해야합니다. 주문이 수락되지 않은 경우 2xx를 반환하지 마십시오. HTTP는 애플리케이션 프로토콜이므로 잊지 마십시오. 2xx를 반품하면 고객은 본문에 보낸 정보에 관계없이 주문이 수락 된 것으로 간주 할 수 있습니다.

---

에서 RESTful 웹 서비스 요리 책 :

일부 웹 서비스의 일반적인 실수 중 하나는 성공을 반영하는 상태 코드 (200에서 206 및 300에서 307의 상태 코드)를 반환하지만 오류 조건을 설명하는 메시지 본문을 포함하는 것입니다. 이렇게하면 HTTP 인식 소프트웨어가 오류를 감지하지 못합니다. 예를 들어 캐시는이를 성공적인 응답으로 저장하고 클라이언트가 성공적인 요청을 할 수있는 경우에도 후속 클라이언트에 제공합니다.

4xx와 5xx 사이에서 결정하도록 맡기겠습니다.하지만 오류 상태 코드를 사용해야합니다.

---

클라이언트가 오류를 해결하기 위해 요청을 수정할 수있는 경우 클라이언트 오류에 4xx를 사용해야합니다. 클라이언트가 실제로 해결할 수없는 서버 오류에는 5xx를 사용하십시오.

품절 된 상품은 서버 오류입니다. 클라이언트는 오류를 해결하기 위해 어떤 방식 으로든 요청을 수정할 수 없습니다. 다른 제품으로 전환 할 수 있지만 새로운 요청이 아닐까요?

사용자 최대 주문 한도에 도달 한 것도 서버 오류입니다. 클라이언트가 해당 오류를 해결하기 위해 수행 할 수있는 작업은 없습니다.

신용 카드 거래 실패는 클라이언트 오류입니다. 클라이언트는 오류를 해결하기 위해 다른 결제 방법 또는 신용 카드 번호로 요청을 다시 제출할 수 있습니다.

---

오류 유형 :

4×× Client Error

에러 코드:

422 Unprocessable Entity

서버는 요청 엔티티의 컨텐츠 유형을 이해하고 (따라서 415 지원되지 않는 미디어 유형 상태 코드가 부적절 함) 요청 엔티티의 구문이 올바르지 만 (따라서 400 잘못된 요청 상태 코드가 부적절 함) 포함 된 항목을 처리 할 수 ​​없습니다. 명령.

예를 들어,이 오류 조건은 XML 요청 본문에 올바른 형식 (즉, 구문 적으로 올바른)이 포함되어 있지만 의미 상 잘못된 XML 명령이 포함 된 경우 발생할 수 있습니다.

https://httpstatuses.com/422

---

이 질문이 오래되었다는 것을 알고 있지만 오늘도 똑같은 질문을 내놓았습니다. 사용자의 크레딧이 부족한 경우 REST API에서 어떤 상태 코드를 반환해야합니까?

나는 다음쪽으로 기울이는 경향이 있습니다 402 Payment Required.

Wikipedia 에 따르면 :

향후 사용을 위해 예약되었습니다. 원래 의도는이 코드가 어떤 형태의 디지털 현금이나 소액 결제 방식의 일부로 사용될 수 있다는 것이었지만, 그런 일이 발생하지 않았으며이 코드는 일반적으로 사용되지 않습니다. Google Developers API는 특정 개발자가 일일 요청 한도를 초과 한 경우이 상태를 사용합니다.

그리고 실제로 그들은 :

PAYMENT_REQUIRED (402)

• 개발자가 설정 한 일일 예산 한도에 도달했습니다.
• 요청 된 작업에는 할당량이 허용하는 것보다 더 많은 리소스가 필요합니다. 작업을 완료하려면 결제가 필요합니다.
• 요청 된 작업에는 인증 된 사용자로부터 일종의 지불이 필요합니다.

---

어때요 424 Failed Dependency? 사양은 다음과 같이 설명합니다.

요청 된 작업이 다른 작업에 종속되어 해당 작업이 실패했기 때문에 리소스에서 메서드를 수행 할 수 없습니다.

But there is also this definition:

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.

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, "action" is quite a broad term, and can be used in a variety of situations, including insufficient stock, insufficient credit, or warehouse party night.

---

Another option might be 422 Unprocessable Entity:

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.

Trying to request an item which is out of stock, or when you have insufficient credit, could be considered a mistake at the semantic level.

---

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 503 Service Unavailable

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.

---

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.

---

I go with 406 Not Acceptable.

Here's a 4xx list:

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

참고URL : https://stackoverflow.com/questions/9381520/what-is-the-appropriate-http-status-code-response-for-a-general-unsuccessful-req