REST API가 500 내부 서버 오류를 리턴하여 쿼리가 존재하지 않는 오브젝트를 참조 함을 표시해야합니까?

여러 IoT 장치의 데이터를 처리하는 서버에있는 REST API로 작업하고 있습니다.

내 임무는 API를 사용하여 서버를 쿼리하여 해당 장치에 대한 특정 성능 정보를 수집하는 것입니다.

어떤 경우에는 사용 가능한 장치 및 해당 식별자 목록을 얻은 다음 나중에 해당 식별자 (GUID)를 사용하여 자세한 내용을 서버에 쿼리합니다.

서버가 500 Internal Server Error해당 ID 중 하나에 대한 쿼리를 반환 합니다. 내 응용 프로그램에서 예외가 발생하고 오류에 대한 세부 정보가 표시되지 않습니다. Postman으로 응답을 자세히 살펴보면 서버가 다음을 포함하는 본문에서 JSON을 반환 한 것을 알 수 있습니다.

errorMessage: "This ID does not exist".

서버가 ID를 제공했다는 사실을 무시하십시오. 이는 개발자에게는 별개의 문제입니다.

REST API 500 Internal Server Error가 존재하지 않는 객체를 쿼리가 참조한다고보고 하기 위해를 반환해야합니까 ? 내 생각에 HTTP 응답 코드는 API의 내부 메커니즘이 아닌 REST 호출의 상태를 엄격하게 참조해야합니다. 200 OK오류와 설명이 포함 된 응답으로 문제의 API에 독점적 인 것으로 기대합니다 .

REST 호출이 구성되는 방식에 따라 예상되는 차이가 있습니다.

다음 예를 고려하십시오.

1. http://example.com/restapi/deviceinfo?id=123
2. http://example.com/restapi/device/123/info

첫 번째 경우, 장치 ID는 GET 변수로 전달됩니다. 404 또는 500은 경로 ( /restapi/deviceinfo)를 찾을 수 없거나 서버 오류가 발생 했음을 나타냅니다 .

두 번째 경우, 장치 ID는 URL의 일부입니다. 나는에 대해 더 많이 이해 404 Not Found하고 있지만 여전히 경로의 어느 부분이 변수 대 끝점으로 해석되는지에 근거하여 논쟁 할 수 있습니다.

404 응답이 여기에서 가장 의미 적으로 일치한다고 생각합니다. 검색하려는 URI (조회에 사용 된 URI로 표시)를 찾으려고했기 때문에 찾을 수 없기 때문입니다. 본문에 오류 페이로드를 반환하는 것은 합리적이지만 필수는 아닙니다.

RFC 2616 에 따르면 404 상태 코드의 정의는 다음과 같습니다.

10.4.5 404 찾을 수 없음
서버가 Request-URI와 일치하는 것을 찾지 못했습니다. 조건이 일시적인지 영구적인지에 대한 표시는 없습니다. 410 (Gone) 상태 코드는 서버가 내부적으로 구성 가능한 메커니즘을 통해 오래된 리소스를 영구적으로 사용할 수없고 전달 주소가 없음을 알고있는 경우 사용해야합니다. 이 상태 코드는 일반적으로 서버가 요청이 거부 된 이유를 정확히 밝히지 않거나 다른 응답이없는 경우에 사용됩니다.

나는 당신의 예를 사용할 것입니다.

http://example.com/restapi/deviceinfo?id=123

끝 점이 json array를 반환하면 200 OK결과를 찾지 못한 경우 빈 배열을 사용하는 것이 가장 좋습니다 .

엔드 포인트가 반환하도록 설계된 경우 하나의 결과를 , 내 선택이 될 것이다 404 NOT FOUND, 나를 위해, 엔드 포인트의 종류에 대한 올바른 구문이기 때문에, : http://example.com/restapi/deviceinfo/123. 필자는 일반적으로 요청 매개 변수를 필터링 및 끝 점이 배열을 반환 할 때만 사용합니다.

http://example.com/restapi/device/123/info

나는이 질문이 이미 여기에 대답되었다고 생각한다 . POST 또는 GET의 404 NOT FOUND경우 리소스 123를 찾을 수 없기 때문에 더 나은 선택이 될 것 입니다.

두 경우 모두 요청이 완료되지 않은 이유를 설명 할 필요가 없습니다. 요청 정보와 HTTP 코드는 이미 그 이유를 설명합니다.

HTTP 404 서버는 클라이언트가 요청한 리소스를 이해하지만 해당 리소스가 없기 때문에 정확합니다.

"REST API"로 작업하고 있다는 사실이 핵심입니다. API는 함수를 실행하지 않고 REpresentational State Transfer를 수행하는 것처럼 작동해야합니다. (물론 "REST"라는 용어는 더 넓은 의미를 가지게되었지만 여기서도 그대로 적용하려면 문자 그대로의 의미를 사용할 수 있습니다.) 클라이언트가 URL에 설명 된 자원의 상태를 요청했습니다 http://example.com/restapi/device/123/info. 쿼리 문자열 ( /deviceinfo?id=123)은 상황을 변경하지 않습니다. 서버는 장치 123의 상태를 전송하라는 메시지를 알고 있지만이를 알려진 리소스로 인식하지 못합니다. 따라서 HTTP 404.

여기에서 논의 된 다른 가능한 답변들도 특정한 의미를 가지고 있습니다 :

• HTTP 200-우리는 당신을 위해 상태를 얻었다; 응답 본문에 있습니다.
• HTTP 204-우리는 당신을 위해 상태를 얻었다; 비어 있습니다.
• HTTP 400-어떤 리소스를 요구하는지 알 수 없습니다. URL을 수정하십시오.
• HTTP 500-오작동했습니다. 당신의 잘못이 아닌.

RFC 2616 초 참조 . 적절하게 10.

5xx 오류는 일반적으로 서버에 오류가 발생하여 요청을 완료 할 수 없음을 나타내는 데 사용됩니다. 서버가 요청을 받아 성공적으로 구문 분석 한 다음 작동하면 5xx 오류를 반환하지 않아야합니다.

쿼리가 결과를 얻지 못하면 반환 할 내용에 대한 규칙이 있는지 확실하지 않습니다. 설명 한 내용 (메시지를 포함하는 본문이있는 200)과 결과를 찾을 수 없음을 나타내는 404를 모두 보았습니다. 200은 아마도 요청이 성공적으로 완료되었으며 클라이언트 요청에 문제가 없거나 서버가 요청을 처리하는 동안 가장 의미가 있습니다. 본문은 클라이언트에게 메시지를 전달할 수 있습니다.

나는 두 가지 예 ( http://example.com/restapi/deviceinfo?id=123와 http://example.com/restapi/device/123/info)를 동일 하게 취급합니다 - 123매개 변수입니다. 두 경우 모두 ID가 123 인 장치에 대한 장치 정보를 얻기 위해 요청을 구성하는 다른 방법입니다.

먼저 권한 부여 및 인증을 고려합니다. 사용자에게 적절한 권한이 없으면 403 또는 401을 적절하게 반환합니다. "허가되지 않음"이라고하더라도 401은 인증에 대한 것이고 403은 무단 또는 권한 거부에 관한 것입니다. 모든 인증 및 권한 부여 오류에 대해 403을 고수하려는 경우 여기에서 너무 까다 롭지 않을 것입니다.

그런 다음 ID를 처리합니다. 귀하의 예에 따르면 숫자 ID 인 것처럼 보입니다. 숫자가 아닌 값을 제공 한 경우 400을 반환합니다. 매개 변수가 유효한 장치 식별자 일 수 있으면 처리를 계속합니다. 다른 인수가 있으면 여기에서도 확인됩니다. 응답 본문에 요청이 잘못된 이유에 대한 적절한 정보가 포함되어있을 것으로 기대합니다.

모든 매개 변수가 유효하면 요청을 처리하기 시작합니다. 시스템이나 의존성 (데이터베이스, 타사 서비스, 다른 내부 서비스)을 사용할 수 없으면 5xx 코드를 반환합니다. 503은 구체적이지만 500도 허용됩니다. 두 경우 모두 추가 세부 정보가 포함 된 본문을 반환합니다. 외부 종속성이 408 요청 시간 초과를보고하는 경우이 요청을 먹고 내 클라이언트에 500을 반환하여 내 시스템에 대한 요청 시간이 초과 된 경우에만 클라이언트가 408을 수신 할 수 있습니다. 시스템이 요청을 완료 할 수 있으면 200과 해당 본문을 반환합니다.

204는 경우에 따라 유용 할 수 있지만 응답 본문을 보내지 못하게합니다. 특히 API 설정에서 로깅 또는보고 메커니즘에 제공 할 수있는 정보가 포함 된 응답 본문을 보내는 것은 대부분의 경우 올바른 결정으로 보입니다.

404가 리턴되는 유일한 시간은 서버에 /deviceinfo엔드 포인트 또는 엔드 포인트 가없는 경우 /device/:id/info입니다.

발견되지 않은 자원과 동일하지 않은 ID는 고려하지 않습니다. 리소스는 특정 장치 (예 :)에 대한 장치 정보입니다. 404를 반환하면 리소스 (장치 정보)가 존재하지 않는 것입니다. 적절한 본체가있는 200은 시스템이 실제로 장치 정보를 제공 할 수 있음을 의미합니다. 지정된 ID를 가진 장치가있을 수도 있고 없을 수도 있습니다.

500 시리즈 HTTP 오류는 서버 오작동을 나타냅니다. 501 Not Implementedand 와는 별도로이 505 HTTP Version Not Supported오류 코드를 사용하면 나중에 요청을 다시 시도하면 성공할 수 있습니다 ( 503 Service Unavailable명시 적으로 만 명시되어 있음). 버그없는 소프트웨어를 작성하고 서버에 무한한 리소스를 제공 할 수 없다는 점에서 서버는 이러한 코드 중 하나를 생성하지 않는 것이 이상적입니다.

"객체가 존재하지 않음"결과의 경우 404 Not Found(요청이 이름으로 요청 된 경우) 또는 200 Success비어있는 결과 본문 (속성별로 개체를 검색 할 때 )을 리턴해야합니다 . 204 No Content유혹적인 것처럼 보이지만 응답 본문이 부족한 상황에서만 사용합니다.

이 호출 중 하나를 수행하면 API 클라이언트로 :

1. http://example.com/restapi/deviceinfo?id=123
2. http://example.com/restapi/device/123/info

나는 DeviceInfo형식적인 형식이든 문서화 된 "덕 형식"규칙을 따르는 것이 든 개체 (또는 어쨌든 특정 형식 )를 되 찾을 것으로 기대한다 . 나는 200실제로 하나를 얻었음을 의미 하는 상태를 원하고 계속 사용할 수 있습니다.

REST API의 경우 400 및 500 상태 코드를 예외와 같은 것으로 생각합니다. 수신 한 요청에 대해 "정상"응답을 리턴 할 수없는시기를 표시하기 위해이를 사용하므로 클라이언트는 검색 할 정보를 처리하는 대신 예외적 인 작업을 수행해야합니다.

이는 API 소비자로서 응답을 검색하거나 예외를 발생시키는 일종의 확인 된 나머지 호출 함수를 사용할 수 있음을 의미합니다. 대단하다. 내 정상적인 논리는 직선 코드 일 수 있으며 로컬 코드에서와 같은 방식으로 오류 처리를 구성 할 수 있습니다. 예기치 않은 404는 나중에 객체 인 { errorMessage: "Device 123 not found" }것처럼 처리 할 때 "속성 누락"오류가 아니라 아무 것도하지 않아도 "자원을 찾을 수 없음"예외로 나타납니다 DeviceInfo.

끝 http://example.com/restapi/deviceinfo 점이 발견 되었다고 판단하고 끝 이id=123 아닌 것으로 판단하고 본문에 오류 메시지와 함께 200을 반환하면 C 함수와 정확히 같은 종류의 인터페이스 문제가 발생하는 것입니다. 올바른 결과 또는 오류 코드 또는 임의로 반환하여 문제를 나타내는 방법null. 인터페이스 사용자는 정기적 인 수익과 "별도의"채널을 통해 오류를 표시하는 것이 훨씬 좋습니다. HTTP 200, 404 및 500 응답이 저수준 관점에서 동일한 채널이지만 여기에도 적용됩니다. REST 클라이언트 프레임 워크는 표준화되고 구분하기 쉬우므로 REST 클라이언트 프레임 워크가 해당 상태를 쉽게 전환하여 내 언어로 적절한 구조로 전환 할 수 있습니다. JSON 레이어 (항상 200이라고 말하고 DeviceInfo오류 메시지)를 사용 하여 동일한 작업을 수행 하려면 사용하는 JSON 스키마에 대한 지식이 필요합니다.

따라서 예상되는 유형의 유효한 값을 반환 할 수있는 경우에만 200을 사용하십시오 (따라서 http://example.com/restapi/search-devices?colour=blue파란색 장치가없는 경우 빈 배열로 200을 반환 할 수 있습니다. 빈 배열은 유효한 배열이며 요청에 대한 합리적인 대답은 "I 모든 파란색 기기의 세부 정보를 원합니다 "). 당신이 할 수 없다면, 가장 적절한 비 200 상태 코드를 사용하십시오. 비록 "존재하지 않는 장치 (123)가" "나에게 장치 (123)의 세부 사항을 제공"에 대한 올바른 대응이며, 대한 오류가 아닙니다 서버 , 그들이 다시 얻을거야 클라이언트의 기대에 대한 예외 DeviceInfo및해야한다은 정상적인 "여기에 요청한 내용"응답으로 전달되지 않습니다.

오류 422 처리 할 수 없는 엔티티 를 사용 하여 404 를 찾을 수 없습니다 . 422는 서버가 요청을 이해하지만 적절한 응답을 제공 할 수 없음을 의미합니다. 비슷한 상황 에서이 코드를 사용하고 있습니다.

오류 500은 일반적으로 요청이 서버 측 프로그램과 충돌했음을 나타냅니다. 기업 환경에서 이러한 오류는 얼굴에서 난으로 취급되며 피해야합니다.

오류 4xx는 API 엔드 포인트 (자원)가 존재하지 않음을 프로그래머에게 신호해야합니다. 결과적으로, 적절한 엔드 포인트에 도달하면 해당 시점부터의 모든 오류 처리는 API 프로그래머의 책임입니다. 즉, 200 응답의 오류 메시지로 정상적으로 처리해야합니다.

w3은 다른 응답이 적용되지 않을 때 404가 사용된다고 언급하지만 204 (No Content) 응답이 적합하지 않습니까? 요청이 처리 관점에서 유효했으며 서버가 요청을 처리했으며 결과가 발생했습니다. 그것은 2xx 응답에 의존하는 성공입니다. 이 특정 요청에 대한 내용이 없었으므로 204는 사용자에게 쿼리에 아무런 문제가 없지만 아무것도 없다는 것을 알려줍니다.

409 (충돌)가 적절한 응답이라는 약한 사례를 만들 수도 있습니다. 409가 POST에 가장 많이 사용되지만

리소스의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수있는 상황에서만 허용됩니다. 응답 본문에는 사용자가 충돌의 원인을 인식 할 수있는 충분한 정보가 포함되어야합니다. 이상적으로, 응답 엔티티는 사용자 또는 사용자 에이전트가 문제를 해결하기에 충분한 정보를 포함 할 것이다. 그러나 불가능할 수도 있고 필요하지 않을 수도 있습니다.

요청 된 ID가 존재하지 않는 것은 여기서의 충돌이며, 시스템에 해당 ID가 존재하지 않는다는 메시지를 사용자에게 반환하면 충돌을 인식하고 수정하기에 충분한 정보가 사용자에게 있습니다.

다른 답변은 그것을 다루고 있지만, 나는 500 시리즈 오류가 "엉망이되었다"는 것을 지적하고 싶었습니다. 이 경우 "I"는 API를 의미하므로 처리되지 않은 서버 오류 또는 이와 유사한 것입니다. 400 시리즈 오류는 "당신이 엉망이되었습니다"를 의미합니다. API 호출자가 잘못된 것을 보냈습니다.

다른 사용자가 책을 보려고 할 때 수행 할 작업에 대한 올바른 답변을 제공했습니다.

그러나 나는 당신이 RESTfulness를 너무 많이 읽고 그것에 대해 절대적으로 정결 한 것을 제안합니다.

REST는 변덕스러운 프로토콜입니다. 책을 사용하는 동안 책을 가고 싶다면 클라이언트와 서버 모두가 REST를 통해 통신하고 있다는 사실을 구체적으로 알고 있어야합니다. 사용은 추상화 될 수 없습니다.

다른 접근 방식이 있습니다. RESTfulness를 완전히 피하고 통신 프로토콜로만 사용하십시오. 즉, 통신 프로토콜에 관한 한 통신 시도는 두 가지 결과 만 가질 수 있기 때문에 리턴해야하는 응답은 "HTTP 200 OK"및 "HTTP 500 내부 서버 오류"뿐입니다. 서버로 전달되거나 전달되지 않습니다.

전달 후 발생하는 일은 통신 프로토콜의 비즈니스가 아닙니다. 따라서, 서버가 요청을 성공적으로 수신하고 처리를 시작하면 많은 오류가 발생할 수 있지만 이는 통신 프로토콜의 비즈니스에 대해 전혀 알지 못하는 모든 응용 프로그램 특정 오류입니다. 통신 프로토콜이 알고있는 한 완벽하게 성공한 응답의 페이로드 내에서 통신해야합니다.

결론적으로, "HTTP 200 OK"를 반환하는 것이 좋으며 응답 페이로드 (HTTP 용어의 "응답 내용 본문") 내에 "ID를 찾을 수 없음"또는 무엇이든 말하는 특정 응용 프로그램 오류 코드가 있습니다.