RFC7807가 제시한 오류 메시지 생성하기

개요 목적

REST API에서 클라이언트 요청에 에러가 발생 했을 때, 서버는 HTTP status 에러 code를 보낸다. (400 bad request, 404 not found) 

하지만, HTTP status code만으로 에러의 원인을 정확히 파악하기 힘들다. 그 때 사용하는 것이, Response Body에 에러에 대한 정보를 담은 오류 메시지를 보내는 것이다.

이제 문제는 오류 메세지에 어떤 내용을 담을 지 생각해야 한다. 이런 고생을 덜어주는 것이, RFC 7807 표준이다.

이번 시간에는 RFC7807 제시한 오류 메세지의 구성과 내용에 대해서 알아보자.

오류 메시지 사용 시 주의사항

• 에러 상황에 맞는 적절한 HTTP status code를 제시하는 데 먼저 집중해야 한다.
• 단순 에러코드만 리턴하지 않고 human-readable한 정보를 포함하도록 한다.
• 서비스 운영 환경에서는 보안에 유의해야한다.

운영 시 일반적인 서비스 구조에서는 에러 스택정보를 API 에러 메세지에 포함 시키지 않는 것이 바람직 하다.

옵션에 따라 dev 모드등으로 기동시, REST API의 에러 응답 메세지에 에러 스택 정보를 포함해서 리턴하도록 하면, 디버깅에 매우 유용하게 사용할 수 있다.

RFC7807에서 제시한 오류 메시지 구조

총 5개의 필드로 구성되어 있다.

1. type : 에러를 분류하기 위한 URI 식별자
2. title : 에러에 대한 간략한 설명
3. status(optional) : HTTP response code
4. detail : 에러에 대한 자세한 설명
5. instance : 에러 발생 근원 URI

예시) 회원 가입 시, 중복된 login id를 사용하였을 때, 보내는 에러 메시지

{
    "type": "/errors/member/join/duplicate-login-name",
    "title": "DuplicatedLoginName",
    "status": 409, 
    "detail": "Company member join fail due to DuplicatedLoginName",
    "instance": "/api/delivery-service/company/member/join"
} 

예시) 회원 가입 시, 공백이 포함된 Request에 보내는 에러 메시지

{
    "type": "/errors/member/join/blank-input",
    "title": "BlackException",
    "status": 400, 
    "detail": "Company member join fail due to blank input request",
    "instance": "/api/delivery-service/company/member/join"
} 

멘토의 조언

위에서 제시한 RFC7807 구조가 반드시 표준이 되는 것은 아니다.

회사마다, 본인들만의 표준을 만들어서 사용하는 경우가 많다. 에러 메시지를 적용해볼까 생각할 때, 참고해볼 좋은 설계이다.

---

reference

https://pjh3749.tistory.com/273

https://dreamsh19.github.io/error/애플리케이션-에러-코드-설계/