200을보고하지 않고 입력 오류가 발생했을 때 최적의 HTTP 응답 코드는 무엇입니까?
마찬가지로 일부 데이터를 서버에 제출하면 데이터가 잘못되었다고 응답합니다.
사용 하면 경고 / 오류 응답 텍스트를
사용 하는 500서버 문제 가 좋지 않습니다 (캐싱 허용 및 모든 것이 정상이 아닙니다).
사용 및 아무것도 반환하지 않고 요청 된 경로 (스크립트)를 사용할 수 있으면
사용 이 잘못 되었지만 잘 지원됩니까? 적절한 장소에200204404
답변:
API를 만들 때도 같은 문제가있었습니다. 에 해당하는 HTTP 상태 코드를 찾고있었습니다 InvalidArgumentException. 아래의 소스 기사를 읽은 후 다음 422 Unprocessable Entity상태를 사용했습니다.
422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (구문 적으로 올바른)이지만 의미 상 잘못된 XML 명령어가 포함 된 경우이 오류 조건이 발생할 수 있습니다.
출처 : https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
4 (4xx)로 시작하는 코드는 클라이언트 오류를위한 것입니다. 이 경우 400 (잘못된 요청)이 적합 할 수 있습니까? http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html의 정의 는 다음과 같습니다.
"잘못된 구문 때문에 서버가 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다."
400 Bad Request나쁘지는 않지만 일반적으로 형식이 잘못된 구문을 위해 예약되어야합니다. OP는 구문이 잘 구성되어 있지만 잘못된 값이있는 경우에 더 관심이있는 것 같습니다. 또한 400은 매우 일반적인 "오 헛된 일이 아니었다"응답 코드로, 특정 경우의 잘못된 입력과 구별 할 수 있습니다.
RFC 사양 이외에도이 기능을 실제로 확인할 수 있습니다. 트위터 응답을 확인하십시오.
https://developer.twitter.com/en/docs/ads/general/guides/response-codes
409 Conflict 수용 가능한 솔루션이 될 수 있습니다.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 에 따르면
자원의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수있는 상황에서만 허용됩니다. 응답 본문에는 사용자가 충돌의 원인을 인식 할 수있는 충분한 정보가 포함되어야합니다 (SHOULD). 이상적으로, 응답 엔티티는 사용자 또는 사용자 에이전트가 문제를 해결하기에 충분한 정보를 포함 할 것이다. 그러나 이는 불가능할 수도 있으며 필요하지 않습니다.
문서는 예제로 계속됩니다.
PUT 요청에 대한 응답으로 충돌이 발생할 가능성이 높습니다. 예를 들어, 버전 관리를 사용 중이고 PUT중인 엔티티에 이전 (타사) 요청으로 작성된 자원과 충돌하는 자원에 대한 변경 사항이 포함 된 경우 서버는 409 응답을 사용하여 요청을 완료 할 수 없음을 표시 할 수 있습니다 . 이 경우 응답 엔티티는 응답 Content-Type에 의해 정의 된 형식으로 두 버전 간의 차이점 목록을 포함 할 수 있습니다.
필자의 경우 API를 통해 데이터베이스에 고유 한 문자열을 PUT하고 싶습니다. 데이터베이스에 추가하기 전에 데이터베이스에 아직 없는지 확인하고 있습니다.
그렇다면을 반환 "Error: The string is already in the database", 409합니다.
나는 이것이 OP가 원하는 것이라고 믿습니다. 데이터가 서버의 기준을 통과하지 못할 때 적합한 오류 코드입니다.
아래 시나리오에 따르면
누군가가 올바른 형식이지만 "좋은"데이터가 아닌 데이터로 서버에 요청한다고 가정 해 봅시다. 예를 들어 누군가 누군가 문자열 값을 예상하는 API 엔드 포인트에 문자열 값을 게시했다고 가정 해보십시오. 그러나 문자열 값에는 블랙리스트에 올린 데이터가 포함되어 있습니다 (예 : 사람들이 "암호"를 암호로 사용하지 못하도록 방지). 상태 코드는 400 또는 422 일 수 있습니까?
지금까지 w3.org에 따르면 "400 잘못된 요청"을 반환했을 것입니다.
잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.
이 설명은 상황에 맞지 않습니다. 그러나 HTTP / 1.1 프로토콜에 정의 된 핵심 HTTP 상태 코드 목록으로 가면 아마도 가장 좋은 방법 일 것입니다.
그러나 최근에 내 개발자 팀의 누군가가 인기 API가 HTTP 확장을 사용하여 오류보고에 대해보다 세분화되기 시작했다고 지적했습니다. 특히 Twitter 및 Recurly와 같은 많은 API는 WebDAV의 HTTP 확장에 정의 된 "422 Unprocessable Entity"상태 코드를 사용하고 있습니다. HTTP 상태 코드 422 상태 :
422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (구문 적으로 올바른)이지만 의미 상 잘못된 XML 명령어가 포함 된 경우이 오류 조건이 발생할 수 있습니다.
위의 비밀번호 예제로 돌아가서이 422 상태 코드는 훨씬 더 적합하다고 생각합니다. 서버는 당신이하려는 일을 이해합니다. 제출하는 데이터를 이해합니다. 단순히 데이터를 처리 할 수 없습니다.
404-찾을 수 없음-다음에 사용할 수 있습니다. 요청한 URI가 유효하지 않거나 사용자와 같이 요청 된 리소스가 존재하지 않습니다.