유효하지 않은 데이터에 대한 REST 응답 코드

다음 시나리오의 경우 클라이언트에게 어떤 응답 코드를 전달해야합니까?

1. 잘못된 이메일 형식과 같이 사용자 등록 중에 잘못된 데이터가 전달되었습니다.
2. 사용자 이름 / 이메일이 이미 존재합니다

나는 403을 선택했다. 나는 또한 내가 사용할 수 있다고 생각하는 것을 발견했다.

위키 백과 :

412 전제 조건 실패 : 서버가 요청자가 요청한 전제 조건 중 하나를 충족하지 않습니다.

403 이외의 것을 사용해야하는 경우 코드를 제안하십시오.

두 경우 모두 400이 최선의 선택입니다. 오류를 더 명확하게 설명하려면 이유 문구를 변경하거나 오류를 설명하는 본문을 포함시킬 수 있습니다.

412-사전 수정 실패는 최종 수정 날짜 및 ETag를 사용할 때 조건부 요청에 사용됩니다.

403-금지는 서버가 자원에 대한 액세스를 방지하려고 할 때 사용됩니다.

가능한 다른 선택은 422-처리 불가능한 엔티티입니다.

422를 권장합니다. 기본 HTTP 사양의 일부는 아니지만 공개 표준 (WebDAV)으로 정의되며 다른 4xx 상태 코드와 동일한 브라우저로 처리해야합니다.

에서 RFC 4918 :

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

요청을 올바르게 구문 분석 할 수없는 경우 (요청 엔티티 / 본문 포함) 적절한 응답은 400 잘못된 요청입니다 [ 1 ].

RFC 4918에 따르면 요청 엔터티가 구문 적으로 잘 구성되어 있지만 의미 상 잘못된 경우 422 처리 할 수없는 엔터티 가 적용 가능 하다고 명시 되어 있습니다. 따라서 요청 엔터티가 잘못된 전자 메일 형식과 같이 왜곡 된 경우 400을 사용하십시오. 그러나 그것이 타당하지 않다면 @example.com422를 사용하십시오.

문제에서 언급 한 것처럼 사용자 이름 / 이메일이 이미 존재 하는 경우 충돌에 대한 설명과 함께 문제를 해결하는 방법에 대한 힌트와 함께 409 충돌 [ 2 ]을 사용할 수 있습니다 (이 경우 " 다른 사용자 이름 / 이메일 "). 그러나 작성된 사양에서 403 Forbidden [ 3 ]을 사용할 수도 있지만 HTTP 인증에 대한 인수에도 불구하고 사용할 수 있습니다.

412 Precondition Failed [ 4 ]는 클라이언트If-Match 가 제공 한 사전 조건 요청 헤더 (예 :)가 false로 평가 될 때 사용됩니다 . 즉, 클라이언트는 무언가를 요청하고 전제 조건을 제공하여 해당 전제 조건이 실패 할 수 있음을 충분히 알고 있습니다. 412는 절대로 클라이언트에게 튀어 나와서는 안되며 요청 엔티티 자체 와 관련되어서는 안됩니다 .

418 I'm a teapotCSRF 확인 실패 또는 요청 속성 누락과 같이 명백하게 조작되었거나 악의적이고 "발생할 수없는"요청 으로 돌아가는 것이 재미 있습니다.

2.3.2 418 나는 주전자입니다

주전자로 커피를 추출하려고하면 오류 코드 "418 주전자입니다"가 표시됩니다. 결과 엔터티 본문은 짧고 튼튼 할 수 있습니다.

합리적으로 심각하게 유지하기 위해 재미있는 오류 코드 사용을 사용자에게 직접 노출되지 않는 RESTful 끝점으로 제한합니다.