요청에 필수 매개 변수가없는 경우 어떤 HTTP 상태 응답 코드를 사용해야합니까?
412 (전제 조건 실패)를 생각하고 있지만 더 나은 표준이 있습니까?
상태 422는 사양 에 따라 가장 적합한 것으로 보입니다 .
422 (처리 할 수없는 엔티티) 상태 코드는 서버가 요청 엔티티의 컨텐츠 유형을 이해하므로 (415 (지원되지 않는 매체 유형) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (잘못된 요청) ) 상태 코드는 부적절하지만 포함 된 지침을 처리 할 수 없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (구문 적으로 올바른)이지만 의미 상 잘못된 XML 명령어가 포함 된 경우이 오류 조건이 발생할 수 있습니다.
그들은 잘못된 XML이 잘못된 구문의 예라고 말합니다 (400을 호출 함). 잘못된 형식의 쿼리 문자열은 이와 유사 해 400이 매개 변수가없는 올바른 형식의 쿼리 문자열에 적합하지 않은 것 같습니다.
@DavidV 업데이트 는이 사양이 핵심 HTTP가 아닌 WebDAV에 대한 것임을 올바르게 지적합니다. 그러나 일부 인기있는 WebDAV API는 더 나은 상태 코드가 없기 때문에 어쨌든 422를 사용하고 있습니다 ( this 참조 ).
표준 설정이 확실하지 않지만 400 Bad Request다음 을 사용했을 것입니다 .
잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.
.NET 의 WCF APIHTTP 404 는 webHttpBinding을 사용할 때 "Endpoint Not Found"오류 를 리턴하여 누락 된 매개 변수를 처리합니다 .
는 404 Not Found당신은 그것의 매개 변수 서명과 함께 웹 서비스 메소드 이름을 고려한다면 의미가 있습니다. 즉, 웹 서비스 메소드를 공개하고 LoginUser(string, string)요청 LoginUser(string)하면 후자를 찾을 수 없습니다.
기본적으로 이는 지정한 매개 변수 서명과 함께 호출하는 웹 서비스 메서드를 찾을 수 없음을 의미합니다.
10.4.5 404 찾을 수 없음
서버가 Request-URI와 일치하는 것을 찾지 못했습니다. 조건이 일시적인지 영구적인지에 대한 표시는 없습니다.
는 400 Bad Request, 같은 거트 제안 , 유효한 응답 코드 남아 있지만 나는 일반적으로 낮은 수준의 문제를 표시하는 데 사용됩니다 생각합니다. 이는 잘못된 HTTP 요청, 누락되거나 유효하지 않은 HTTP 헤더 또는 이와 유사한 것으로 쉽게 해석 될 수 있습니다.
10.4.1 400 잘못된 요청
잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.
API 프로젝트 중 하나에서 매개 변수 누락으로 인해 100 %로 완전히 채울 수없는 경우 일부 요청에 409 상태를 설정하기로 결정했습니다.
HTTP 상태 코드 "409 충돌"은 사용자가 충돌의 원인을 인식 할 수 있도록 충분한 정보를 포함해야하기 때문에 좋은 시도였습니다.
참조 : w3.org/Protocols/
따라서 400 또는 404와 같은 다른 응답 중에서 409를 선택하여 새 올바른 요청을 설정하는 데 도움이되는 요청에서 메모를 살펴볼 필요가있었습니다.
어떤 식 으로든 요청이 완전히 정확하지 않은 경우 일부 데이터를 보내야하므로 클라이언트가 메시지를보고 요청에서 무엇이 잘못되었는지 이해하도록 강제해야합니다.
일반적으로 누락 된 매개 변수 만있는 경우 400 및 누락 된 매개 변수 배열 로 이동합니다 . 그러나 특정 사례 메시지와 같은 추가 정보를 보내야 할 때 클라이언트가 처리 할 것인지 더 확실하게 확인하려면 409를 보냅니다.
400 잘못된 요청 코드를 보낼 수 있습니다. 보다 일반적인 4xx 상태 코드 중 하나이므로이를 사용하여 원하는 것을 의미 할 수 있습니다. 클라이언트가 올바르게 처리하기 위해 응용 프로그램에 필요한 정보 / 매개 변수가없는 요청을 보내고 있습니다.
필요한 매개 변수의 내용이 API 끝점과 같은 암호가 너무 짧은 경우 422 (Unprocessable entity)로 이동하지만 누락 된 매개 변수의 경우 406 (허용되지 않음)으로 이동합니다.
나는 종종 403 Forbidden 오류를 사용합니다. 추론은 요청이 이해되었지만 요청 된대로하지 않을 것입니다 (사실이 잘못 되었기 때문에). 응답 엔티티는 문제점을 설명하므로 응답이 HTML 페이지 인 경우 오류 메시지가 페이지에 있습니다. JSON 또는 XML 응답 인 경우 오류 정보가 있습니다.
에서 RFC2616 :
10.4.4 403 금지
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.
승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
요청 방법이 HEAD가 아니고 서버
가 요청이 이행되지 않은 이유 를 공개 하기를 원한다면 , 엔티티에서 거부 이유를 설명해야한다. 서버가이 정보를 클라이언트가 사용할 수 없게하려면 상태 코드 404
(찾을 수 없음)를 대신 사용할 수 있습니다.
404 Not Found지정된 자원을 찾을 수 없으므로 a를 사용해야 한다고 주장 할 수 있습니다 .
관심있는 사람들을 위해 Spring MVC (3.x 이상)는이 경우 400을 반환합니다.
여러 Google URL (accounts.google.com)을 테스트하고 필수 매개 변수를 제거했으며이 경우 일반적으로 404를 반환합니다.
Google을 복사하겠습니다.
나는 403과 함께 갈 것입니다.
에서 RFC 2616 - 하이퍼 텍스트 전송 프로토콜 - HTTP / 1.1
403 금지
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다. 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하기를 원한다면, 엔티티에서 거부 이유를 설명해야한다. 서버가이 정보를 클라이언트가 사용할 수 없게하려면 상태 코드 404 (찾을 수 없음)를 대신 사용할 수 있습니다.
응답에 실패 이유를 설명해야합니다. 원하지 않으면 404를 사용하십시오.
'Programming' 카테고리의 다른 글
| Apache ZooKeeper 설명 (0) | 2020.02.29 |
|---|---|
| 메소드는 다른 유형의 메소드와 동일한 지우기를 갖습니다. (0) | 2020.02.29 |
| ASP.NET 웹 API에서 오류를 반환하는 모범 사례 (0) | 2020.02.29 |
| express.js에서 HTTPS 사용 (0) | 2020.02.29 |
| 암호문을 사용하는 방법? (0) | 2020.02.29 |