[rest] 유효한 요청이지만 빈 데이터에 적합한 REST 응답 코드는 무엇입니까?

빈 데이터로 204 또는 200을 선호하는 404에 강력하게 반대합니다. 또는 적어도 하나는 404와 함께 응답 엔터티를 사용해야합니다.

요청이 접수되어 올바르게 처리되었습니다. 서버에서 응용 프로그램 코드를 트리거했기 때문에 실제로 클라이언트 오류라고 말할 수 없으므로 전체 클라이언트 오류 코드 (4xx) 클래스가 적합하지 않습니다.

더 중요한 것은 404는 여러 가지 기술적 이유로 발생할 수 있습니다. 예를 들어 서버에서 응용 프로그램이 일시적으로 비활성화 또는 제거되고 프록시 연결 문제가 발생하는 등 따라서 클라이언트는 “빈 결과 집합”을 의미하는 404와 “서비스를 찾을 수 없습니다. 나중에 다시 시도하십시오”를 의미하는 404를 구별 할 수 없습니다.

치명적일 수 있습니다. 회사에서 연간 보너스로 인한 모든 직원을 나열하는 회계 서비스를 상상해보십시오. 불행히도 한 번 호출되면 404를 반환합니다. 이는 보너스를받을 사람이 아무도 없거나 현재 새로운 배포를 위해 응용 프로그램이 다운되었음을 의미합니까?

-> 데이터 품질에 관심이있는 애플리케이션의 경우 응답 엔터티가없는 404는 거의 문제가되지 않습니다.

또한 많은 클라이언트 프레임 워크는 추가 질문없이 예외를 발생시켜 404에 응답합니다. 이로 인해 클라이언트 개발자는 해당 예외를 잡아서 평가 한 다음이를 모니터링 구성 요소에 의해 발생한 오류로 기록할지 또는 무시할지 여부에 따라 결정해야합니다. 그것은 나에게도 예쁘지 않은 것 같습니다.

404에 비해 404의 장점은 요청 된 리소스를 찾지 못한 이유에 대한 정보를 포함 할 수있는 응답 엔터티를 반환 할 수 있다는 것입니다. 그러나 이것이 실제로 관련이 있다면 200 OK 응답 사용을 고려하고 페이로드 데이터에서 오류 응답을 허용하는 방식으로 시스템을 설계 할 수도 있습니다. 대안 적으로, 구조화 된 정보를 호출자에게 리턴하기 위해 404 응답의 페이로드를 사용할 수있다. 예를 들어 파싱 할 수있는 XML 또는 JSON 대신 html 페이지를 수신하는 경우 이는 호출자의 관점에서 유효 할 수있는 “결과 없음”응답 대신 기술적 인 문제가 발생했음을 나타내는 좋은 지표입니다. 또는 HTTP 응답 헤더를 사용할 수도 있습니다.

여전히 나는 빈 응답으로 204 또는 200을 선호합니다. 이렇게하면 요청의 기술적 실행 상태가 요청의 논리적 결과와 분리됩니다. 2xx는 “기술적 실행은 괜찮습니다. 결과입니다. 처리합니다”.

나는 빈 결과가 허용되는지 아닌지를 결정하기 위해 클라이언트에게 맡겨야한다고 생각합니다. 올바른 기술적 실행에도 불구하고 응답 엔터티없이 404를 반환함으로써 클라이언트는 단순히 오류가 아닌 오류로 간주 할 수 있습니다.

또 다른 빠른 비유 : “결과 없음”에 대해 404를 반환하는 것은 SQL 쿼리에서 결과가 반환되지 않은 경우 DatabaseConnectionException을 발생시키는 것과 같습니다. 작업을 수행 할 수는 있지만 동일한 예외를 발생시키는 유효한 기술적 인 원인이 많이 있으며 유효한 결과로 오인 될 수 있습니다.

답변

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /users/kyle              404     Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content