좋은 에러 응답 고민하기

Good Error Response

Issue

친하지만 한번도 같이 프로젝트를 해본적 없는 동료와 프로젝트를 시작하게 되었다. 좋은 프로젝트, 코드 등 업무 관련해서 다양한 대화를 할 수 있는 좋은 동료다. 그래서 함께 프로젝트를 시작하는 것이 좋았다.

우리는 현재 회사의 에러 응답에 대한 규칙, 형식을 요번 기회에 정해보자고 했다. 그래서 Facebook, Google 등 대기업의 에러 응답도 분석해보고 글을 읽으며 우리들만의 규칙을 정했다.

Solution

code(에러 번호), message(메세지), description(설명)를 에러의 기본 형태로 정했다.

code를 카테고라이징하여 맨앞자리가 분류를 나타내고, message를 통해 code의 이름을 알려주고, 설명을 통해 상황마다의 자세한 설명을 넣기로 하였다. 그리고 이를 정리한 것을 엑셀로 정리하여 공유하기로 했다.

도움받은 사이트

• Best Practices for Designing a Pragmatic RESTful API

{
  "code" : 1234,
  "message" : "Something bad happened :(",
  "description" : "More details about the error here"
}

{
  "code" : 1024,
  "message" : "Validation Failed",
  "errors" : [
    {
      "code" : 5432,
      "field" : "first_name",
      "message" : "First name cannot have fancy characters"
    },
    {
       "code" : 5622,
       "field" : "password",
       "message" : "Password cannot be blank"
    }
  ]
}

• 10 Best Practices for Better RESTful API

{
  "errors": [
   {
    "userMessage": "Sorry, the requested resource does not exist",
    "internalMessage": "No car found in the database",
    "code": 34,
    "more info": "http://dev.mwaysolutions.com/blog/api/v1/errors/12345"
   }
  ]
}