HTTP 상태를 사용하여 응용 프로그램 환경에 알립니다.

Question

범죄 기록부에 질문을 던지십시오 (http://server/demographics/party/ {partyId}). 그 사람은 해당 시스템에 알려져 있지 않습니다. 오류입니까? 좋은 일이 아닌가?

404를 반환하면 오류 코드이며 Restlet은 특정 URL을 서버 리소스 (처리 클래스)에 대한 경로로 해결할 수 없으므로이를 구현했습니다. 이는 잘못된 상황입니다.

제 생각에는 시스템이 호출을 이해하고 오류없이 처리 할 수 ​​있다면 200 (HTTP-ok)을 반환해야하며 "우리는이 사람을 모른다"라는 정보를 반환해야합니다. .

가장 좋은 방법은 무엇입니까?

Answer 1

은 404 상태 코드를 반환하지 않습니다. 단순히 "당신이 자원을 요청했는데 존재하지 않습니다"라는 의미입니다. 그것이 200을 반환했다면, 어떻게 든 모든 상태가 잘되었음을 알리는 추가 상태 코드를 반환해야하지만, 자원을 찾을 수 없습니다. 그것은 404가 이미 정확히 의미하기 때문에 불필요합니다.

상태 500은 일반적으로 "무언가 잘못되었습니다. 자원이 존재하는지 여부를 알 수 없습니다"라는 의미로 반환됩니다. 이제 당신이 404를 반환했다면, 이것은 실수 일 것입니다.

좋은 점이 있건 없건간에 HTTP 또는 REST와 관련이 없습니다. 그리고 BTW, 등록 원이 재해의 생존자를 포함하는 파일 인 경우, 실제로 법에있어서 당신의 어머니를 사랑하지 않는 한, 당신이 법에있어서 당신의 어머니 인 경우를 제외하고는, 당신이 찾은 사람을 찾지 않는 것이 좋지 않을 것입니다 . (이것은 분명하지 않은 사람들을위한 농담이다).

Answer 2

웹 서비스는 두 가지 종류의 응답을 생성하는 방식으로 구현 될 수 있습니다.

HTTP/Rest보다 더 진실한 방식으로 구현되고 있다면 '404 not found'가 뭔가를 찾지 못하는 것에 대한 적절한 응답이 될 것입니다. 이것이 바로 404 상태입니다.

귀하의 요청은 '나는이 기록이 있다고 가정하고보고 싶다'고 생각하고 404 응답은 '기록이 존재하지 않는다'고 말하는 것으로 도움이 될 수 있습니다.

브라우저에서 표시하는 대신이 URL을 코드에서 사용하려는 경우 응답 상태를 구분하지 않으면 응답 본문에 추가 정보를 추가해야합니다. 차이를 분명히하십시오.

이 URL은 브라우저에서 사용자에게 표시 할 것입니다 경우, 서버는 여전히에 대한 응답 본문의 내용을 표시 할 수있는 404

Answer 3

읽어 보시기 바랍니다 : http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1

인용 :

결론 :

• 사람이 읽을 수있는 오류 메시지 : REST 기반 웹 서비스의 주요 매력의 일부는 어떤 브라우저 유형을 열 수 있다는 것입니다 정확한 URL을 입력하고 즉각적인 응답을 확인하십시오. 특별한 도구는 필요하지 않습니다. 그러나 HTTP 오류 코드가 항상 충분한 정보를 제공하지는 않습니다. 예를 들어 위의 옵션 1을 선택하고 책 ID를 요청하고 유효하지 않으면 404 오류 코드가 반환됩니다. 개발자 관점에서 잘못된 호스트 이름이나 잘못된 책 ID를 실제로 입력 했습니까? 즉각적인 것은 아닙니다.옵션 3 (DAS)에서는 정보가없는 빈 페이지가 반환됩니다. 실제 오류 코드를 보려면 네트워크 스니퍼를 실행하거나 프록시를 통해 브라우저를 가리켜 야합니다. 이러한 모든 이유 때문에 옵션 4가 제공해야 할 부분이 많습니다. 새로운 개발자의 장벽을 크게 낮추고 웹 서비스와 관련된 모든 정보를 웹 브라우저에서 직접 볼 수 있습니다.
• 응용 프로그램 특정 오류 : 옵션 1은 브라우저에서 직접 볼 수 없다는 단점이 있습니다. 또한 모든 HTTP 오류 코드를 응용 프로그램 특정 오류 코드에 매핑하는 추가 단점이 있습니다. HTTP 상태 코드는 문서 검색 및 게시에만 해당되며 응용 프로그램 도메인에 직접 매핑되지 않을 수 있습니다. 예를 들어, DAS 오류 코드 중 하나는 유효하지 않은 게놈 좌표 (시퀀스 좌표가 범위를 벗어났습니다/유효하지 않음)와 관련이 있습니다. 이 경우 어떤 HTTP 오류 코드가 매핑됩니까?
• 기계 판독 가능한 오류 코드 : 세 번째 기준으로 다른 응용 프로그램에서 오류 코드를 쉽게 읽을 수 있어야합니다. 예를 들어, XooMLe 응용 프로그램은 사람이 읽을 수있는 오류 메시지 만 반환합니다. "잘못된 Google API 키가 제공되었습니다." XooMLe 응답을 구문 분석하는 응용 프로그램은이 특정 오류 메시지를 검색해야합니다. 예를 들어 XooMLe 서버가 메시지를 "Invalid Key Supplied"로 간단히 변경할 수 있습니다. DAS에서 제공하는 것과 같은 오류 코드는 프로그래밍 방식의 제어 및 예외 작성이 중요합니다. 예를 들어 XooMLe가 1001 오류 코드를 반환하면 클라이언트 응용 프로그램에서 빠른 검색을 수행하고 즉시 InvalidKeyException을 throw 할 수 있습니다.
  • 를 사용하여 HTTP 상태 특히 HTTP 관련된 문제에 대한 코드, 특히 웹 서비스에 관련되지 않은 :이 세 가지 기준에 따라

  , 여기에 최고의 오류 처리 옵션에 대한 내 투표입니다.

• 오류가 발생하면 항상 오류를 설명하는 XML 문서를 반환하십시오.
• XML 오류 문서에 오류 코드와 사람이 읽을 수있는 오류 메시지가 모두 포함되어 있는지 확인하십시오. 예를 들어 : 잘못된 구글 API 키는이 세 가지 간단한 방법을 다음으로

를 제공, 당신은 훨씬 더 쉽게 다른 서비스와 인터페이스 할 수 있도록하고, 일이 잘못 갈 때 반응 할 수 있습니다. 새로운 개발자는 단순한 웹 브라우저를 통해 유효하거나 유효하지 않은 요청을 쉽게 볼 수 있으며 프로그램은 오류 코드를 쉽게 추출 할 수 있으며 더 강력하게 사용할 수 있습니다. Amazon.com 웹 서비스 API는 반환 된 XML 문서의 접근 방식을 따라 ErrorMsg 요소를 지정할 수 있습니다. XooMLe도이 방법을 사용합니다. (XooMLe는 기존 SOAP 기반 Google API에 RESTful API 래퍼를 제공합니다.) 또 다른 접근법은 DAS (Distributed Annotation System)입니다. HTTP 오류가없는 경우 항상 200을 반환하고 브라우저가 표시하지 않으므로 사람이 읽을 수 없으므로 덜 우호적 인 HTTP 헤더에 오류 정보가 있습니다 HTTP 헤더.