HTTP 헤더 또는 응답 본문에 나머지 오류 메시지가 있습니까?

Question 1

iPhone 및 Android 클라이언트에 노출되는 REST 서비스가 있습니다. 현재 HTTP 코드 200, 400, 401, 403, 404, 409, 500 등을 따릅니다.

내 질문은 오류의 원인 / 설명 / 원인을 입력하는 권장 장소는 어디입니까? REST API가 항상 헤더에 사용자 정의 Reason을 갖는 것이 더 합리적입니까?

< HTTP/1.1 400 Bad Request - Missing Required Parameters.
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked

아니면 JSON을 통해 응답 본문에 포함하는 것이 더 낫습니까?

< HTTP/1.1 400 Bad Request
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json
{ "error" : "Missing Required Parameters" }

Question 2

400.x 오류 코드에 대한 HTTP 사양에서 인용 :

4xx 클래스의 상태 코드는 클라이언트가 오류가있는 것으로 보이는 경우를위한 것입니다. HEAD 요청에 응답 할 때를 제외하고, 서버는 오류 상황에 대한 설명과 그것이 일시적 또는 영구적 조건인지 여부를 포함하는 엔티티를 포함해야합니다 (SHOULD). 이러한 상태 코드는 모든 요청 방법에 적용 할 수 있습니다. 사용자 에이전트는 포함 된 모든 엔티티를 사용자에게 표시해야합니다.

오류 메시지를 HTTP 응답 본문에 엔티티로 포함하는 것이 가장 좋습니다 (JSON, 일반 텍스트, 형식화 된 HTML 또는 활용할 수있는 기타 형식).

Question 3

본문에 오류 세부 정보가있는 것이 좋습니다. 또한 많은 (대부분 / 거의 모든, 예 : WSGI) 서버 및 클라이언트는 오류 코드의 이름 변경을 지원하지 않습니다. 고정 된 쌍으로 취급합니다 (예 : 400은 항상 "잘못된 요청"이 아니라 "잘못된 요청-사용자 사용자 ID를 지정하는 것을 잊었습니다 "). 고장 나지 않더라도 특정 오류 코드에 대한 특별한 이름은 신경 쓰지 않습니다.

Question 4

오류는 본문에 속하지 않습니다. 경고 헤더에 속합니다.

경고 일반 HTTP 헤더에는 메시지 상태의 가능한 문제에 대한 정보가 포함되어 있습니다.

참고

Question 5

나는 항상 둘 다합니다. 나는 보통 "409-새 사용자를 추가 할 수 없습니다. 이미 존재합니다."와 같이 프런트 엔드가 사용자에게 친숙한 방식으로 표시 할 수있는 상태 메시지를 설정합니다.

그런 다음 UI 개발자가 수행 할 작업에 대해 지능적인 선택을 시도 할 수 있도록 본문에 오류 조건의 세부 정보를 JSON으로 포함합니다.

{
  "status": 409,
  "message": "The user <username> was already added on <when> by <who> and given the user id 12345.",
  "errors": {
    "id": 12345
  }
}