데이터의 POST에 대한 400 대 422 응답

현재 작업중인 "REST와 같은"API를 사용하여 다른 시나리오에서 올바른 상태 코드가 반환되는 것을 알아 내려고합니다. JSON 형식의 POST 구매를 허용하는 엔드 포인트가 있다고 가정 해 봅시다. 다음과 같이 보입니다 :

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

클라이언트가 "sales_tax"(예상 "tax"대신)를 보내면 어떻게해야합니까? 현재 400을 반환하고 있습니다. 그러나 이에 대해 의문을 가지기 시작했습니다. 정말로 422를 반환해야합니까? 내 말은 JSON (지원되는)이고 유효한 JSON이며 필요한 필드가 모두 포함되어 있지 않습니다.

400 잘못된 요청 이 이제 사용 사례에 가장 적합한 HTTP / 1.1 상태 코드 인 것 같습니다.

귀하의 질문 (및 내 원래 답변) 당시 RFC 7231 은 문제가되지 않았습니다. RFC 2616이 다음과 같이 말했기 400 Bad Request때문에 이의를 제기 한 시점은 다음 과 같습니다.

구문이 잘못되어 서버가 요청을 이해할 수 없습니다 .

설명하는 요청은 구문 적으로 유효한 HTTP에 포함 된 구문 상 유효한 JSON이므로 서버는 요청 구문 에 문제가 없습니다 .

그러나 코멘트에 리 Saferite가 가리키는 아웃로 , RFC 2616을 쓸모 없게 RFC 7231, 그 제한은 포함되지 않습니다 :

400 (잘못된 요청) 상태 코드는 클라이언트 오류 (예 : 잘못된 요청 구문, 잘못된 요청 메시지 프레이밍 또는 사기성 요청 라우팅)로 인식되는 것으로 인해 서버가 요청을 처리 할 수 ​​없거나 처리하지 않음을 나타냅니다.

그러나 그 단어를 다시 말하기 전에 (또는 RFC 7231에 대해 제안 된 표준 일뿐입니다 ) RFC 4918에 소개 된 것처럼 다음 과 같이 사용 사례에 잘못된 HTTP 상태 코드 422 Unprocessable Entity가 아닌 것 같습니다 .

HTTP / 1.1에서 제공하는 상태 코드는 WebDAV 메소드에서 발생하는 대부분의 오류 조건을 설명하기에 충분하지만 기존 범주에 속하지 않는 일부 오류가 있습니다. 이 사양은 WebDAV 방법을 위해 개발 된 추가 상태 코드를 정의합니다 (11 장)

그리고 설명은422 말합니다 :

422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 ​​없습니다.

(구문에 대한 언급을 참고하십시오; 7231은 4918도 부분적으로 쓸모없는 것으로 의심됩니다)

이것은 당신의 상황과 똑같이 들리지만 의심이있는 경우를 대비하여 다음과 같이 말합니다.

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

( "XML"을 "JSON"으로 바꾸면 귀하의 상황에 동의 할 수 있습니다.)

이제 RFC 4918은 "WebDAV (Web Distributed Authoring and Versioning)를위한 HTTP 확장"에 관한 것이며 WebDAV와 관련하여 아무 것도하지 않을 것이므로이를 사용해서는 안된다고 반대 할 것입니다.

상황을 명시 적으로 다루지 않는 원래 표준에서 오류 코드를 사용하는 것과 상황을 정확하게 설명하는 확장 중 하나를 사용하는 것 중에서 선택하면 후자를 선택합니다.

또한 RFC 4918 섹션 21.4 는 IANA 하이퍼 텍스트 전송 프로토콜 (HTTP) 상태 코드 레지스트리를 참조 하며 여기서 422를 찾을 수 있습니다.

HTTP 클라이언트 또는 서버가 올바르게 레지스트리를 유지하는 한 해당 레지스트리의 상태 코드를 사용하는 것이 합리적이라고 제안합니다.

그러나 HTTP / 1.1부터 RFC 7231 에는 견인력이 있으므로 사용하십시오 400 Bad Request!

400 잘못된 요청 은 사용 사례에 적합한 HTTP 상태 코드입니다. 코드는 HTTP / 0.9-1.1 RFC에 의해 정의됩니다.

잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 처리 불가능한 개체 는 RFC 4918-WebDav에 의해 정의됩니다. 400과 비교하면 약간의 차이가 있습니다. 아래 인용 된 텍스트를 참조하십시오.

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

균일 한 인터페이스를 유지하려면 XML 응답의 경우에만 422를 사용해야하며 422뿐만 아니라 Webdav 확장으로 정의 된 모든 상태 코드도 지원해야합니다.

http://tools.ietf.org/html/rfc4918#page-78

상태 코드에 대한 Mark Nottingham의 게시물을 참조하십시오.

애플리케이션의 각 부분을 "깊게"HTTP 상태 코드에 매핑하려고 시도하는 것은 실수입니다. 대부분의 경우 목표로 삼고 싶은 입도 수준이 훨씬 더 거칩니다. 확실하지 않은 경우 일반 상태 코드 200 OK, 400 Bad Request 및 500 내부 서비스 오류를 사용하는 것이 더 적합하지 않은 경우 괜찮습니다 .

HTTP 상태 코드에 대해 생각하는 방법

2015 년 현재 상태를 반영하려면 :

400 및 422 응답 코드는 모두 클라이언트와 중개자에 의해 동일하게 취급되므로 실제로 사용하는 구체적인 차이 는 없습니다 .

그러나 400이 현재 더 널리 사용되는 것을 기대하고 있으며 HTTPbis 사양이 제공 하는 설명 으로 인해 두 가지 상태 코드 중 더 적합합니다.

• HTTPbis 스펙은 구문 오류만을위한 것이 아닌 400의 의도를 명확하게합니다. "클라이언트 오류로 인식 된 것으로 인해 서버가 요청을 처리 할 수 ​​없거나 처리 할 수 ​​없음을 나타내는"이라는 문구가 이제 사용되었습니다.
• 422 특히 WebDAV 확장이며 RFC 2616 또는 최신 HTTPbis 사양 에서는 참조되지 않습니다 .

문맥 상, HTTPbis는 명확하지 않거나 일관성이없는 영역을 명확하게하기 위해 HTTP / 1.1 사양의 개정판입니다. 승인 상태에 도달하면 RFC2616을 대체합니다.

사례 연구 : GitHub API

https://developer.github.com/v3/#client-errors

잘 알려진 API에서 복사하는 것이 현명한 아이디어 일 수 있습니다.

요청 본문을 수신하는 API 호출에 가능한 세 가지 유형의 클라이언트 오류가 있습니다.

잘못된 JSON을 보내면 400 잘못된 요청 응답이 발생합니다.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

잘못된 유형의 JSON 값을 보내면 400 잘못된 요청 응답이 발생합니다.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

유효하지 않은 필드를 보내면 422 처리 할 수없는 엔티티 응답이 발생합니다.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

정답은 없습니다. 요청에 대한 "구문"의 정의에 따라 다릅니다. 가장 중요한 것은 다음과 같습니다.

1. 응답 코드를 일관되게 사용하십시오
2. API를 사용하는 개발자가 진행 상황을 파악할 수 있도록 응답 본문에 추가 정보를 추가하십시오. =

모두가 여기에 옳고 그른 대답이 없다고 말하면서 나를 뛰어 넘기 전에 내가 결론에 도달 한 방법에 대해 조금 설명하겠습니다.

이 특정 예에서 OP의 질문은 예상과 다른 키를 포함하는 JSON 요청에 관한 것입니다. 이제, 수신 된 키 이름은 자연어 관점에서 예상 키와 매우 유사하지만, 엄격하고 다르며, 기계에 의해 (보통) 동등한 것으로 인식되지 않습니다.

위에서 말했듯이 결정 요소는 구문의 의미 입니다. 요청의 콘텐츠 유형과 함께 전송 된 경우 application/json, 다음 네, 요청은 구문 이 유효 JSON 구문입니다,하지만 때문에 유효한 의미 가 예정되어 일치하지 않기 때문에, 유효합니다. (문제의 요청을 의미 론적으로 유효하게 만드는 이유에 대한 엄격한 정의를 가정).

반면에 요청이보다 구체적인 맞춤 콘텐츠 유형으로 전송 된 경우 application/vnd.mycorp.mydatatype+json 예상되는 필드를 정확하게 지정하면 요청이 구문 적으로 유효하지 않을 수 있으므로 400 응답이 가능합니다.

이후 문제의 경우, 키가 잘못이 아니라이었다 값이 하는 거기 구문 오류가 사양이 있다면 유효한 키가 무엇인지에 대한. 유효한 키에 대한 스펙이 없거나 오류에 값 이 있으면 의미 오류입니다.

422 처리 불가능한 엔티티 설명 업데이트 : 2017 년 3 월 6 일

422 처리 할 수없는 엔터티 란 무엇입니까?

요청이 올바르게 구성되면 422 상태 코드가 발생하지만 의미 오류로 인해 처리 할 수 ​​없습니다. 이 HTTP 상태는 RFC 4918에 도입되었으며보다 구체적으로 WebDAV (Web Distributed Authoring and Versioning)를위한 HTTP 확장에 맞춰져 있습니다.

개발자가 클라이언트에 400 대 422 오류를 반환해야하는지 여부에 대한 논란이 있습니다 (아래 두 상태의 차이점에 대한 자세한 내용). 그러나 대부분의 경우 WebDAV 기능을 지원하는 경우에만 422 상태가 리턴되어야한다는 데 동의합니다.

RFC 4918의 11.2 절에서 가져온 422 상태 코드의 단어 별 정의는 아래에서 읽을 수 있습니다.

422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 ​​없습니다.

정의는 계속해서 말합니다.

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

400 대 422 상태 코드

잘못된 요청 오류는 400 상태 코드를 사용하며 요청 구문이 잘못되었거나 잘못된 요청 메시지 프레이밍이 포함되어 있거나기만적인 요청 라우팅이있는 경우 클라이언트에 반환해야합니다. 이 상태 코드는 422 처리 할 수없는 엔티티 상태와 매우 유사 해 보이지만이를 구별하는 하나의 작은 정보는 422 오류에 대한 요청 엔티티의 구문은 정확하지만 400을 생성하는 요청의 구문은 사실입니다 오류가 잘못되었습니다.

422 상태의 사용은 매우 특정한 사용 사례에 대해서만 예약되어야합니다. 잘못된 형식의 구문으로 인해 클라이언트 오류가 발생한 대부분의 경우 400 잘못된 요청 상태를 사용해야합니다.

https://www.keycdn.com/support/422-unprocessable-entity/

귀하의 경우 : HTTP 400 보낼의 구문 적으로 잘못된 같은 REST 관점에서 사건에 대한 올바른 상태 코드 sales_tax대신에 tax자사의 유효한 JSON 불구하고. 이것은 일반적으로 JSON을 객체에 매핑 할 때 대부분의 서버 측 프레임 워크에서 시행됩니다. 그러나 keyJSON 객체의 새로운 기능을 무시하는 일부 REST 구현이 있습니다. 이 경우 content-type서버 측에서 유효한 필드 만 허용 하는 사용자 지정 규격을 적용 할 수 있습니다.

422를위한 이상적인 시나리오 :

이상적인 세계에서, 서버가 요청 엔터티의 콘텐츠 유형을 이해하고 요청 엔터티의 구문이 정확하지만 의미 적으로 잘못되어 데이터를 처리 할 수없는 경우 , 422 가 선호되고 일반적으로 응답으로 전송하는 것이 허용됩니다.

422 이상의 400 상황 :

응답 코드 422는 확장 HTTP (WebDAV) 상태 코드입니다. 422를 처리 할 준비가되지 않은 일부 HTTP 클라이언트 / 프런트 엔드 라이브러리가 있습니다. "HTTP 422가 아니기 때문에 HTTP가 아닙니다" 와 같이 단순 합니다. 서비스 관점에서 400은 구체적이지 않습니다.

엔터프라이즈 아키텍처에서 서비스는 주로 SOA, IDM 등과 같은 서비스 계층에 배포됩니다. 일반적으로 아주 오래된 기본 클라이언트에서 최신 HTTP 클라이언트에 이르는 여러 클라이언트에 서비스를 제공합니다. 클라이언트 중 하나가 HTTP 422를 처리하지 않는 경우 옵션은 클라이언트에게 모든 사람을 위해 응답 코드를 HTTP 400으로 업그레이드하거나 변경하도록 요청하는 것입니다. 내 경험상 이것은 요즘 매우 드물지만 여전히 가능성이 있습니다. 따라서 HTTP 응답 코드를 결정하기 전에 항상 아키텍처에 대한 신중한 연구가 필요합니다.

이와 같은 상황을 처리하기 위해 서비스 계층은 일반적으로 엄격한 HTTP 준수 클라이언트가 400을 전송하고 나머지는 422를 전송하도록 엄격한 플래그를 사용 versioning하거나 설정 configuration플래그를 사용 합니다. 이렇게하면 기존 소비자에게 이전 버전과의 호환성 지원을 제공하지만 동시에 새 클라이언트가 HTTP 422를 사용할 수있는 기능을 제공합니다.

RFC7321 의 최신 업데이트 는 다음과 같습니다.

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

이는 서버가 유효하지 않은 요청에 대해 HTTP 400을 전송할 수 있음을 확인합니다. 400은 더 이상 구문 오류만을 참조하지는 않지만 422는 클라이언트가 처리 할 수 ​​있다면 여전히 진정한 응답입니다.

첫째, 이것은 매우 좋은 질문입니다.

400 잘못된 요청-요청에서 중요한 정보가 누락 된 경우

예를 들어 인증 헤더 또는 콘텐츠 유형 헤더. 서버가 요청을 이해하기 위해 반드시 필요한 것입니다. 서버마다 다를 수 있습니다.

422 처리 할 수없는 엔티티-요청 본문을 구문 분석 할 수없는 경우

이것은 400보다 덜 심각합니다. 요청이 서버에 도달했습니다. 서버는 요청이 기본 구조 권한을 가지고 있음을 인정했습니다. 그러나 요청 본문의 정보는 구문 분석하거나 이해할 수 없습니다.

예를 들어 Content-Type: application/xml요청 본문이 JSON 인 경우

다음은 상태 코드와 REST API에서의 사용법을 나열한 기사입니다. https://metamug.com/article/status-codes-for-rest-api.php

실제로 "200 OK"를 반환해야하며 응답 본문에 게시 된 데이터에서 발생한 일에 대한 메시지가 포함됩니다. 그런 다음 메시지를 이해하는 것은 응용 프로그램에 달려 있습니다.

문제는 HTTP 상태 코드가 정확히 HTTP 상태 코드라는 것입니다. 그리고 그것들은 응용 계층이 아닌 운송 계층에서만 의미를 갖도록 의도되었습니다. 응용 프로그램 계층은 실제로 HTTP가 사용되고 있음을 절대 알 수 없습니다. 전송 계층을 HTTP에서 Homing Pigeons로 전환 한 경우 응용 프로그램 계층에 영향을 미치지 않아야합니다.

비가 상적인 예를 드리겠습니다. 당신이 소녀와 사랑에 빠지고 그녀가 당신을 사랑하지만 그녀의 가족이 완전히 다른 나라로 이사한다고 가정 해 봅시다. 그녀는 새 달팽이 메일 주소를 알려줍니다. 당연히, 당신은 그녀에게 연애 편지를 보내기로 결정합니다. 편지를 쓰고 봉투에 넣고 봉투에 주소를 쓰고 우표를 붙여서 보내십시오. 이제이 시나리오들을 고려해 봅시다

1. 거리 이름을 쓰는 것을 잊었습니다. 주소가 잘못되었다는 메시지와 함께 열지 않은 편지를 받게됩니다. 요청을 망 쳤고 수신 우체국에서 처리 할 수 ​​없습니다. "400 Bad Request"를받는 것과 같습니다.
2. 따라서 주소를 수정하고 편지를 다시 보내십시오. 그러나 약간의 불운으로 인해 거리의 이름을 완전히 틀 렸습니다. 주소가 존재하지 않는다는 메시지와 함께 편지를 다시 받게됩니다. "404 Not Found"를받는 것과 같습니다.
3. 주소를 다시 수정하면 이번에는 주소를 올바르게 쓸 수 있습니다. 당신의 소녀는 편지를 받고 당신을 다시 씁니다. "200 OK"를받는 것과 같습니다. 그러나 이것이 그녀가 편지에 쓴 것을 좋아한다는 의미는 아닙니다. 그것은 단순히 그녀가 당신의 메시지를 받고 당신을 위해 응답한다는 것을 의미합니다. 봉투를 열고 편지를 읽을 때까지는 그녀가 당신을 그리워하거나 헤어지고 싶어하는지 알 수 없습니다.

간단히 말해 "200 OK"를 반환한다고해서 서버 앱에 좋은 소식이있는 것은 아닙니다. 그것은 단지 뉴스가 있다는 것을 의미합니다.

추신 : 422 상태 코드는 WebDAV의 맥락에서만 의미가 있습니다. WebDAV로 작업하지 않는 경우 422는 다른 비표준 코드 =와 동일한 표준 의미를 갖습니다.