우리는 문서 컬렉션을 반환하는 RESTful API를 설계하고 있습니다. 초기 구현에서는 HTTP 상태 코드를 사용하여 요청을 수행 할 수 없었는지 여부를 나타냅니다. 이것은 널리 받아 들여지는 제일 연습 인 것을 보인다 (예를 들면 here를보십시오).수집 결과에 대해 RESTful API에서 예외를 어떻게 처리해야합니까?
최근에 사용자가 1000 개의 문서를 가져 오는 문제가 발생했습니다. 문서 검색 중 하나가 실패하여 HTTP 500 상태 코드가 반환되었습니다.
다른 방법으로는 검색 할 수있는 999 개의 문서가있는 페이로드와 함께 HTTP 200 상태 코드를 반환 한 다음 실패한 메시지를 나타내는 오류 컬렉션을 반환하는 것입니다.
이 대체 방법은 RESTful 원칙을 위반합니까? 이 상황을 어떻게 처리해야합니까? 이 두 가지 접근법 외에 다른 옵션이 있습니까?
예, 반환하는 데이터에 "오류"컬렉션이 포함될 수 있다는 것을 문서화하는 한 완전히 받아 들일 수 있습니다. 즉,이 문서 모음을 설명하는 데 사용하는 의미 적 미디어 유형에는 문서 모음의 모양과 오류 컬렉션의 모양을 설명하는 문서가 있어야합니다. 그러면 클라이언트는이 정보로 수행 할 작업을 결정할 수 있습니다. 당신은 JSON (단지 예)로이를 반환하는 경우
는 예를 들어, 다음과 같이 할 수 application/json+documents이나 뭐 같은 미디어 타입,있을 수 있습니다 : 당신은 다음 문서를 것
{ data : {
documents: [ ... ], //document objects
errors: [ ... ] //error objects
}
을 그 문서의 모양과 오류 모양을 설명합니다. 진정으로 RESTful API의 경우 진정한 RESTful API에서는 단 하나의 엔드 포인트 만 있고 다른 모든 것은 의미 엔드 미디어 유형과 함께 초기 엔드 포인트를 통해 "발견"되기 때문에 호출이 아니라 문서화 된 미디어 유형이다. 따라서 오류가 발생할 수 있다는 것을 문서화하고 오류가 전달 될 형식을 설명하면 문제가 없습니다.
클라이언트가 모든 문서를 검색 할 수 없다는 것을 예상 할 수 있기 때문에 이는 "예외적 인"조건도 아닙니다. 그러므로 그 사실을 고객에게 알리는 것이 좋습니다.
다음과 같은 고유 한 상황에서 교차해야하는 경우가 있습니다. 사용자 관련.
사용자에게 페이로드가 너무 큼을 알리고 내부 서버 오류를 반환하는 것은 무리가 아닙니다.
감사를 위해 Vivin을 입력하십시오. 그래서 상황이 "예외적 인"것으로 간주되는지 아닌지 가능한 분할 선을 추측합니다. 그렇다면 HTTP 500 상태가 리턴되어야합니다. 상황이 예외는 아니며 API의 정상적인 사용의 일부로 정기적으로 발생할 것으로 예상 될 수 있다면 (잘 문서화 된!) 페이로드 콘텐츠에 오류 정보를 보내면 HTTP 200이 더 적절할 수 있습니다. –
@JoeAlfano 수정. 사용자가 실제로 복구 할 수없는 실제 예외 인 경우 HTTP 500이 정상입니다. 그렇지 않으면 오류와 함께 보유하고있는 부분 데이터를 제공 할 수 있으며 사용자는이를 처리하는 방법을 결정할 수 있습니다. –