유효성 검사 실패 또는 잘못된 중복에 대한 REST HTTP 상태 코드

REST 기반 API로 응용 프로그램을 작성 중이며 각 요청에 대해 상태 코드를 지정하는 시점에 도달했습니다.

유효성 검사에 실패하거나 요청이 데이터베이스에서 복제본을 추가하려고하는 경우 어떤 상태 코드를 보내야합니까?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html을 살펴 보았지만 어느 것도 옳지 않은 것 같습니다.

상태 코드를 보낼 때 일반적인 관행이 있습니까?

입력 검증 실패의 경우 : 400 잘못된 요청 + 선택적 설명. 이것은 " RESTful Web Services " 책에서 제안됩니다 . 이중 제출 : 409 충돌

2014 년 6 월 업데이트

관련 사양 은 RFC2616 으로 400 (Bad Request)을 다소 좁게 사용했습니다.

잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다.

따라서 의미 상 오류에 부적합하다고 주장 되었을 수도 있습니다. 그러나 더 이상은 아닙니다. 2014 년 6 월 이후 이전 RFC2616을 대체 하는 관련 표준 RFC 7231 은 다음과 같이 400 (잘못된 요청)을 보다 광범위하게 사용합니다.

클라이언트 오류로 인식 된 것으로 인해 서버가 요청을 처리 할 수 ​​없거나 처리하지 않습니다.

• 실패한 유효성 검사 : 403 금지됨 ( "서버가 요청을 이해했지만 요청을 거부하고 있습니다"). 대중의 의견과 달리 RFC2616은 "403은 인증 실패만을위한 것"이라고 말하지 않지만 "403 : 원하는 것을 알고 있지만 그렇게하지는 않습니다"라고 말합니다. 이 상태는 인증 때문일 수도 있고 아닐 수도 있습니다.
• 복제본 추가 시도 중 : 409 충돌 ( "자원의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다.")

응답 헤더 및 / 또는 본문에 더 자세한 설명을 제공해야합니다 (예 : 사용자 정의 헤더- X-Status-Reason: Validation failed).

상태 코드 422, "처리 할 수없는 엔티티"를 권장 합니다 .

11.2. 422 처리 불가능한 개체

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

200,300, 400, 500은 모두 매우 일반적입니다. 일반을 원하면 400이 정상입니다.

422는 점점 더 많은 수의 API에서 사용되며 Rails에서도 즉시 사용됩니다.

API에 대해 어떤 상태 코드를 선택 하든지간에 누군가 동의하지 않을 것입니다. 그러나 '400 + text status'가 너무 일반적이라고 생각하기 때문에 422를 선호합니다. 또한 JSON 준비 파서를 사용하지 않습니다. 반대로 JSON 응답이있는 422는 매우 명시 적이며 많은 오류 정보가 전달 될 수 있습니다.

JSON 응답에 대해 말하자면,이 경우 Rails 오류 응답을 표준화하는 경향이 있습니다.

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

이 형식은 양식 유효성 검사에 적합하며, '오류보고 풍부 성'측면에서 가장 복잡한 경우를 고려합니다. 오류 구조가이 경우 모든 오류보고 요구를 처리 할 수 ​​있습니다.

200

Uh ... (309, 400, 403, 409, 415, 422) ... 성공적인 HTTP 요청 이지만 실패한 REST 호출에 대한 최상의 리턴 코드가 무엇인지 추측, 논쟁 및 표준화하려는 많은 답변이 있습니다.

HTTP 상태 코드와 REST 상태 코드를 혼합하는 것은 잘못 입니다.

그러나 많은 구현이 혼합되어있는 것을 보았으며 많은 개발자가 저에게 동의하지 않을 수 있습니다.

HTTP 리턴 코드는 HTTP Request자체 와 관련이 있습니다. REST 호출은 하이퍼 텍스트 전송 프로토콜 요청을 사용하여 수행되며 호출 된 REST 메소드 자체보다 낮은 레벨에서 작동합니다. REST는 개념 / 접근 방식이며 결과 는 비즈니스 / 논리적 결과이며 HTTP 결과 코드는 전송 코드입니다 .

예를 들어, / users /를 호출 할 때 "404를 찾을 수 없음"을 반환하면 혼동 될 수 있습니다.

• URI가 잘못되었습니다 (HTTP)
• 사용자를 찾을 수 없습니다 (REST)

"403 금지 / 액세스 거부"는 다음을 의미 할 수 있습니다.

• 특별 허가가 필요합니다. 브라우저는 사용자 / 암호를 요청하여이를 처리 할 수 ​​있습니다. (HTTP)
• 서버에 잘못된 액세스 권한이 구성되었습니다. (HTTP)
• 인증이 필요합니다 (REST)

그리고 목록은 '500 서버 오류'(Apache / Nginx HTTP 발생 오류 또는 REST의 비즈니스 제한 오류) 또는 기타 HTTP 오류 등으로 계속 될 수 있습니다.

코드에서 실패 이유, HTTP (전송) 실패 또는 REST (논리) 실패를 이해하기는 어렵습니다.

HTTP 요청이 실제로 성공적으로 수행 된 경우 레코드의 발견 여부에 관계없이 항상 200 코드를 리턴 해야합니다 . URI 자원이 발견 되어 HTTP 서버에 의해 처리 되었기 때문 입니다. 예, 빈 세트를 반환 할 수 있습니다. HTTP 결과로 200을 가진 빈 웹 페이지를 수신 할 수 있습니까?

이 대신 몇 가지 옵션으로 200 HTTP 코드를 반환 할 수 있습니다.

• 무언가 잘못되면 JSON 결과의 "오류"객체
• 레코드를 찾지 못하면 빈 JSON 배열 / 객체
• 보다 나은 처리를 위해 이전 옵션과 결합 된 부울 결과 / 성공 플래그입니다.

또한 일부 인터넷 제공 업체는 귀하의 요청을 가로 채서 404 HTTP 코드를 반환 할 수 있습니다. 이것은 데이터를 찾을 수 없다는 것을 의미하지는 않지만 전송 수준에서 문제가 있습니다.

에서 위키 :

2004 년 7 월 영국의 통신 제공 업체 인 BT Group은 Cleanfeed 콘텐츠 차단 시스템을 구축했습니다.이 콘텐츠 차단은 Internet Watch Foundation에서 불법으로 식별 한 콘텐츠에 대한 요청에 404 오류를 반환합니다. 다른 ISP는 같은 상황에서 HTTP 403 "금지"오류를 반환합니다. 검열을 은폐하기위한 수단으로 가짜 404 오류를 사용하는 관행도 태국과 튀니지에서보고되었습니다. 2011 년 혁명 이전에 검열이 심했던 튀니지에서 사람들은 가짜 404 오류의 본질을 알게되고 "보이지 않는 검열"을 나타내는 "Ammar 404"라는 가상의 캐릭터를 만들었습니다.

왜 이런 식으로 대답하지 않습니까?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

요청이 논리적으로 실패하더라도 Google은 항상 지오 코딩 API에서 상태 코드로 200을 반환합니다. https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

REST 요청이 실패하더라도 Facebook은 HTTP 요청 성공에 대해 항상 200을 반환합니다. https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

간단한 HTTP 상태 코드는 HTTP 요청을위한 것입니다. REST API는 Your이고 상태 코드를 정의하십시오.

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

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

여기 에 4xx 코드에 대한 자세한 설명이 나와 있습니다 .

상태 코드 304 Not Modified 는 중복 요청에 대해 수용 가능한 응답을합니다. 이것은 If-None-Match엔티티 태그 를 사용하는 헤더를 처리하는 것과 유사합니다 .

내 의견으로는 @Piskvor의 대답은 원래 질문의 의도라고 생각하는 것보다 더 분명한 선택이지만 관련있는 대안이 있습니다.

중복 요청을 오류가 아닌 경고 또는 알림으로 처리하려는 경우 응답 상태 코드가 304수정되지 않음 및 Content-Location기존 자원을 식별하는 헤더가 유효합니다. 의도가 단순히 자원이 존재하도록하는 것이라면 중복 요청은 오류가 아니라 확인입니다. 요청이 잘못되지 않았지만 단순히 중복되어 클라이언트가 기존 리소스를 참조 할 수 있습니다.

즉, 요청은 양호하지만 자원이 이미 존재하므로 서버는 추가 처리를 수행 할 필요가 없습니다.

Ember-Data의 ActiveRecord 어댑터는 422 UNPROCESSABLE ENTITY서버에서 리턴 될 것으로 예상 합니다. 따라서 클라이언트가 Ember.js로 작성된 경우 422를 사용해야합니다. 그런 다음 DS.Errors는 반환 된 오류로 채워집니다. 물론 422를 어댑터의 다른 코드 로 변경할 수 있습니다 .