[web-services] REST API 오류 리턴 우수 사례 [닫기]

주요 선택 사항은 HTTP 상태 코드를 REST API의 일부로 처리할지 여부입니다.

두 가지 방법 모두 잘 작동합니다. 엄밀히 말하면 REST의 아이디어 중 하나는 HTTP 상태 코드를 API의 일부로 사용해야한다는 것입니다 (성공적인 작업을 위해서는 200 또는 201을 반환하고 다양한 오류 사례에 따라 4xx 또는 5xx를 반환하십시오). REST 경찰은 없습니다. 당신이 원하는 것을 할 수 있습니다. 나는 훨씬 더 비 심각한 비 REST API가 “RESTful”이라고 불렀습니다.

이 시점에서 (2015 년 8 월) API의 일부로 HTTP 상태 코드를 사용하는 것이 좋습니다. 프레임 워크를 사용할 때 과거보다 리턴 코드를 보는 것이 훨씬 쉽습니다. 특히 200이 아닌 리턴 사례와 200이 아닌 응답 본문을 과거보다 더 쉽게 확인할 수 있습니다.

HTTP 상태 코드는 API의 일부입니다

1. 오류 조건에 맞는 4xx 코드를 신중하게 선택해야합니다. 하위 코드 및 설명 주석이 포함 된 페이로드로 나머지, xml 또는 일반 텍스트 메시지를 포함 할 수 있습니다.

2. 클라이언트는 HTTP 레벨 상태 코드를 얻을 수있는 소프트웨어 프레임 워크를 사용해야합니다. 일반적으로 가능하지만 항상 간단한 것은 아닙니다.

3. 클라이언트는 통신 오류를 나타내는 HTTP 상태 코드와 응용 프로그램 수준 문제를 나타내는 자체 상태 코드를 구분해야합니다.

HTTP 상태 코드는 API의 일부가 아닙니다

1. 앱이 요청을 수신 한 후 응답 한 경우 (성공 및 오류 사례 모두) HTTP 상태 코드는 항상 200입니다.

2. 모든 답변에는 “봉투”또는 “헤더”정보가 포함되어야합니다. 일반적으로 다음과 같습니다.

   envelope_ver : 1.0
   상태 : # 원하는 코드를 사용하십시오. 성공을위한 코드를 예약하십시오.
   msg : "ok"# 코드를 반영하는 인간 문자열. 디버깅에 유용합니다.
   data : ... # 응답의 데이터입니다 (있는 경우).

3. 응답 상태는 항상 동일한 위치 (하위 코드 필요 없음), 코드 제한 없음, HTTP 수준 상태 코드 가져 오기 필요 없음으로 인해이 방법이 더 쉬울 수 있습니다.

비슷한 생각을 가진 게시물이 있습니다 : http://yuiblog.com/blog/2008/10/15/datatable-260-part-one/

주요 이슈:

1. 필요한 경우 나중에 API의 의미를 변경할 수 있도록 버전 번호를 포함하십시오.

2. 문서…

답변

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)