우아한 에러처리를 위해 코드잽만의 에러 코드 정립하기

[Hain-tain]

⚡️ 결정사항

<코드잽 에러코드 규칙>

• 1000: 클라이언트 에러
  • 11xx: 요청 형식 오류 (잘못된 헤더, query-prams, body, http 매서드 전달)
  • 12xx: 리소스 오류 (클라이언트에서 잘못된 엔드포인트 접근, 존재하지 않는 리소스 접근, 중복된 리소스 접근)
  • 13xx: 인증/인가 (권한)
• 2000: 서버 에러

---

📍 회의 주제: 코드잽만의 API통신 에러 코드 정립하기

• 일시: 8월 12일 월요일 오후 3시 ~ 4시
• 장소: 어드레스 회의실(예약 완료)
• 준비물: 노트북 및 에러코드에 대한 자신의 생각

---

🪧 주제에 대한 배경 설명

• http status code와 분리된 우리 서비스 도메인 레벨의 에러코드가 필요하다고 생각함.

  • 500 에러 발생 시, 500 status 코드만 보고 애플리케이션 내부적으로 어떤 에러가 발생했는지 파악하기가 어려움.
  • 그냥 400 bad request 만 오면 개발자가 오류 내부 메세지를 읽으러 들어가야하기 때문에 클라이언트 단에서도 어떤 에러가 발생했는지 파악하기 어려움. 우리 서비스도 아래 사진처럼 400에러가 여러 이유로 발생할 수 있는데, 정확한 원인을 한 번에 알기는 어려움.
    

• 고유한 식별자의 역할을 하는 에러코드를 설정하면 지금보다 에러가 난 경우에 의사소통이 편리해질 것이라고 생각함.

  • 에러의 발생 원인과 형식을 정의해두면 추후 관리가 용이함.
  • 에러가 발생했을 때, '500에러 난다' 가 아니라 '특정에러코드가 난다'라고 말하면 원인 파악이 훨씬 쉽고 소통이 용이함.

위와 같은 이유로 코드잽만의 에러코드를 정립해볼 것을 제안합니다!!

---

🎸기타 참고사항

• 애플리케이션 에러 코드 설계 목적이 잘 나와있는 글
• 블로그 글-Error Code 적용기
• 카카오쇼핑-응답 코드 및 에러 코드
• LG ThinQ Connect API의 응답 코드

[Hain-tain]

현재 코드잽에서 오는 에러 응답

1. 템플릿 CRUD API:

• GET /templates (템플릿 검색)
• POST /templates (템플릿 생성)
  • 400
    • 모든 필드 중 null인 값이 있는 경우
    • 제목 또는 스니펫 파일 또는 태그 이름이 255자를 초과한 경우
    • 썸네일 스니펫의 순서가 1이 아닌 경우
    • 스니펫 순서가 잘못된 경우
    • 스니펫 내용 65,535 byte를 초과한 경우
• GET /templates/{id} (템플릿 단건 조회)
  • 400
    • 해당하는 id 값인 템플릿이 없는 경우
    • 템플릿을 가져올 권한이 없는 경우
• POST /templates/{id} (템플릿 수정)
  • 400
    • 해당하는 id 값인 템플릿이 없는 경우
    • 템플릿을 수정할 권한이 없는 경우
• DELETE /templates/{id} (템플릿 삭제)
  • 400
    • 해당하는 id 값인 템플릿이 없는 경우
    • 템플릿을 수정할 권한이 없는 경우
• GET /templates/tags (태그 목록 조회)
• GET /templates/explore (템플릿 탐색)

2. 카테고리 CRUD API:

• PUT /categories/{id} (카테고리 수정)
  • 400
    • 해당하는 id 값인 카테고리가 없는 경우
    • 동일한 이름의 카테고리가 존재하는 경우
    • 카테고리를 수정할 권한이 없는 경우
• DELETE /categories/{id} (카테고리 삭제)
• 400
  - 삭제하려는 카테고리에 템플릿이 존재하는 경우
  - 카테고리를 삭제할 권한이 없는 경우
• GET /categories (카테고리 목록 조회)
• POST /categories (카테고리 생성)
  • 400
    • 모든 필드 중 null인 값이 있는 경우
    • 카테고리 이름이 255자를 초과한 경우
    • 동일한 이름의 카테고리가 존재하는 경우

3. 인증 및 인가 API:

• POST /signup (회원가입)
  • 400: 요청형식 오류
    • 이메일 입력 없음/이메일 형식 오류/이메일 글자수 오류
    • 비밀번호 입력 없음/비밀번호 형식 오류/비밀번호 글자수 오류
    • 사용자명 입력 없음/사용자명 글자수 오류
  • 409: 중복 오류
    • 이메일 중복
    • 사용자명 중복
• POST /logout (로그아웃)
  • 401 쿠키값오류
• POST /login (이메일 로그인)
  • 400: 요청형식 오류
    • 이메일 입력 없음/이메일 형식 오류/이메일 글자수 오류
    • 비밀번호 입력 없음/비밀번호 형식 오류/비밀번호 글자수 오류
  • 401: 요청형식 오류
    • 이메일 불일치
    • 사용자명 불일치
• GET /login/check (이메일 로그인 후 쿠키 인증)
  • 401 쿠키값 오류
• GET /check-username (사용자명 중복 확인)
  • 409 중복된 사용자명
• GET /check-email (이메일 중복 확인)
  • 409 중복된 이메일

[Jaymyong66]

[Jaymyong66]

추가 의견 :

• 에러에 대한 응답 형식이 일정하지 않음.
• 에러처리가 되어있지 않은 API가 있음

[Jaymyong66]

현재 형식 : IETF

1. type : 세부 에러 코드. (꼭 숫자일 필요는 없음)
2. title : 에러에 대한 간략한 설명
3. status(optional) : HTTP response code
4. detail : 에러에 대한 자세한 설명
5. instance : 에러 발생 근원지 URI

{
  "type": "about:blank",
  "title": "BAD_REQUEST",
  "status": 400,
  "detail": "사용자명이 입력되지 않았습니다.",
  "instance": "/signup"
}

표준 예시

{
    "type": "/errors/incorrect-user-pass",
    "title": "Incorrect username or password.",
    "status": 401, 
    "detail": "Authentication failed due to incorrect username or password.",
    "instance": "/login/log/abc123"
}

[zangsu]

좋아요! 다만, 세부 에러 코드에 대해서는 어떤 코드를 사용할 지 고민이 더 필요하겠네용 🤔

[Jaymyong66]

에러 코드를 한다면 얼마나 상세히 에러 코드로 분류할 것인가?

마위 : 예를 들어 401 쿠키 인증 오류라면 같은 에러 코드로 만들자.
그렇게 된다면 앤드포인트 만큼의 에러코드가 생기지 않아도 된다.
소통한다면? 어느 앤드포인트에서 어떤 에러코드가 났어! 라고 하면 충분히 구체적이지 않을까?

[Jaymyong66]

헤인 : 에러코드는 식별자라고 생각한다. 따라서 같은 종류의 오류라도 앤드포인트마다 에러 코드가 달라져야한다.

[zeus6768]

에러 코드 문서를 따로 관리해야 한다는 점이 걱정이네요.

어디에 저장해서 볼 수 있게 할 생각인가요?

[Jaymyong66]

노션? 엑셀? 위키미키?

[zeus6768]

백엔드에서는 enum 사용을 고려해봐야겠어요.

[Hain-tain]

<코드잽 에러코드 규칙>

• 1000: 클라이언트 에러
  • 11xx: 요청 형식 오류 (잘못된 헤더, query-prams, body, http 매서드 전달)
  • 12xx: 리소스 오류 (클라이언트에서 잘못된 엔드포인트 접근, 존재하지 않는 리소스 접근, 중복된 리소스 접근)
  • 13xx: 인증/인가 (권한)
• 2000: 서버 에러

[Jaymyong66]

제우스, 마위 : 잘못된 메서드는 요청 형식 오류이다
몰리, 헤인 : 아니다 리소스 오류이다. 앤드 포인트는 존재하지만 메서드가 다른 것은 없는 리소스에 대한 요청이다.

켬미, 짱수, 헤인 : 둘다 ㄱㅊ