유효성 검증 실패를 위해 REST API 서비스에서 리턴 할 적절한 HTTP 상태 코드는 무엇입니까?

Django / Piston 기반 REST API 응용 프로그램 에서 유효성 검사 오류가 발생할 때마다 현재 401 Unauthorized를 반환 합니다. HTTP 상태 코드 레지스트리를 살펴본 결과 이것이 유효성 검사 실패에 적합한 코드라고 확신하지 못합니다. 무엇을 권장합니까?

• 400 잘못된 요청
• 401 무단
• 403 금지
• 405 메소드가 허용되지 않습니다
• 406 허용되지 않음
• 412 전제 조건 실패
• 417 기대 실패
• 422 처리 불가능한 개체
• 424 실패한 종속성

업데이트 : 위의 "유효성 검사 실패"는 응용 프로그램 수준 데이터 유효성 검사 실패, 즉 잘못 지정된 날짜 시간, 가짜 전자 메일 주소 등을 의미합니다.

"유효성 확인"이 요청에 클라이언트 오류가 있음을 의미하는 경우 HTTP 400 (잘못된 요청)을 사용하십시오. 예를 들어 URI에 ISO-8601 날짜가 있고 잘못된 형식이거나 2 월 31 일을 참조하는 경우 HTTP 400을 반환합니다. 엔터티 본문에 올바른 형식의 XML이 있으면 구문 분석에 실패합니다.

(1/2016) : 지난 5 년 동안 WebDAV 의보다 구체적인 HTTP 422 (처리 할 수없는 엔티티)는 HTTP 400에 대한 매우 합리적인 대안이되었습니다. 예를 들어 JSON API 에서의 사용을 참조하십시오 . 그러나 HTTP 422는 HTTP 1.1, RFC-7231 로 만들지 않았습니다 .

Richardson과 Ruby의 RESTful 웹 서비스 에는 다양한 HTTP 응답 코드 사용시기에 대한 유용한 부록이 포함되어 있습니다. 그들은 말합니다 :

400 (“나쁜 요청”)
중요도 : 높음.
다른 4xx 오류 코드가 적절하지 않은 경우 사용되는 일반적인 클라이언트 측 오류 상태입니다. 클라이언트가 PUT 또는 POST 요청과 함께 표현을 제출할 때 일반적으로 사용되며 표현이 올바른 형식이지만 의미가 없습니다. (p. 381)

과:

401 (“무단”)
중요도 : 높음.
클라이언트가 적절한 인증 자격 증명을 제공하지 않고 보호 된 리소스에서 작동하려고했습니다. 잘못된 자격 증명을 제공했거나 전혀 제공하지 않았을 수 있습니다. 자격 증명은 사용자 이름과 암호, API 키 또는 인증 토큰 일 수 있습니다 (문제의 서비스가 기대하는 것). 클라이언트가 URI를 요청하고 401을 수락하는 것이 일반적이므로 어떤 종류의 자격 증명을 어떤 형식으로 보내야하는지 알 수 있습니다. [...]

RFC 4918 (및 http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml에 문서화 )에서 :

422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 ​​없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (구문 적으로 올바른)이지만 의미 상 잘못된 XML 명령어가 포함 된 경우이 오류 조건이 발생할 수 있습니다.

데이터베이스의 사본은이어야합니다 409 CONFLICT.

422 UNPROCESSABLE ENTITY유효성 검사 오류에 사용 하는 것이 좋습니다 .

4xx 코드에 대한 자세한 설명은 다음과 같습니다. http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

여기있어:

rfc2616 # section-10.4.1-400 잘못된 요청

구문 이 잘못되어 서버가 요청을 이해할 수 없습니다 . 클라이언트는 수정없이 요청을 반복해서는 안됩니다.

rfc7231 # section-6.5.1-6.5.1. 400 잘못된 요청

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

기형 (잘 구성되지 않은) 사례를 나타냅니다!

rfc4918-11.2. 422 처리 불가능한 개체

422 (처리 할 수없는 엔티티) 상태 코드는 서버
가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티 의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 ​​없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (구문 적으로 올바른)이지만 의미 상 잘못된 XML 명령어 가 포함 된 경우이 오류 조건이 발생할 수 있습니다 .

결론

경험 법칙 : [_] 00은 지정된 코드에서 다루지 않는 가장 일반적인 경우와 사례를 다룹니다.

422 개 맞는 최적의 객체 유효성 검사 오류 (정확하게 내 추천 :
관해서는 의미 오류는 - 검증 "이 사용자 이름이 이미 존재하는"같은 생각.

400은 개체 유효성 검사에 잘못 사용됩니다

기술적으로는 HTTP 실패가 아닐 수 있다고 말하고 싶습니다. 자원이 (아마도) 유효하게 지정되어 있고 사용자가 인증되었으며 작동 실패가 없었습니다 (그러나 사양에는 402 Payment Required와 같은 일부 예약 코드가 포함되어 있음) HTTP와 관련하여 엄격하게 말하면, 모든 장치가 조건을 인식 할 수 있도록 프로토콜 수준에서 사용하는 것이 좋습니다.

이 경우 실제로 응용 프로그램 오류와 같은 상태 필드를 응답에 추가합니다.

<status> <code> 4 </ code> <message> 날짜 범위가 잘못되었습니다 </ message> </ status>

HTTP 1.1을 문서화하는 RFC 2616 에는 이러한 오류의 의미에 대한 정보가 조금 더 있습니다.

개인적으로, 나는 아마 사용할 것입니다 400 Bad Request. 그러나 이것은 실제로지지하지 않는 개인적인 견해 일뿐입니다.

"유효성 검사"란 정확히 무엇을 의미합니까? 무엇을 확인하고 있습니까? 구문 오류 (예 : 잘못된 XML)를 언급하고 있습니까?

이 경우, 400 Bad Request가 옳다고 말할 수 있지만 그것이 무엇인지 "알고 있는지"모릅니다. 말할 수는 없습니다.