클라이언트-서버 간 에러 코드를 정의하는게 어떨까요?

[gitchannn]

RESTful API에서는 에러 상황에 따라서 서버가 적절한 에러 코드를 보내줍니다.
에러 코드를 무시하고 로직을 작성하는 것은 부적절하지만, 그렇다고 너무 정확한 에러 코드를 보내주면 사용자가 개발자도구 창에서 전부 다 볼 수 있기 때문에 이또한 보안적으로 위협이 될 수 있습니다.

우리 서비스에서는 에러 코드를 별도로 정의해서 클라이언트-서버 간 통신에서 사용하는게 어떨까 건의합니다.

크게 로그인 관련, 점역 과정에서 ocr/점역 알고리즘 관련 에러코드를 일단 정의하면 어떨까 합니다 예시

cc. @JunhyeongPark-kr

참고

[jun-brro]

좋습니다..! 에러 코드 번호 -> 에러 명 에서 '에러명' 부분을 새로 정의하자는 내용이 맞을까요? 클라이언트쪽에서 해야될 내용이 있다면 알려주세요!

[gitchannn]

에러 상황을 정의한 뒤에 공유할게요!

[gitchannn]

@JunhyeongPark-kr 백엔드에서 발생할 수 있는 예외상황을 대략적으로 정리했습니다!

앞으로 예상치 못한 상황이 추가될 때마다 새롭게 정의하도록 하죠!
일단은 이렇게 개발했습니다!
대응해야 한다고 생각하는 부분에 대해서는 로직 짜주세요!
저는 아직 사용자에게 에러가 ocr에서 났는지 점역에서 났는지가 그닥 중요하게 생각될 것 같지는 않아서 별도로 대응해야 하는지는 잘 모르겠네요!
로깅용으로는 요긴하게 사용할 수 있을 것 같습니다

✔️ 로그인 관련 에러

• 로그인 필요 없이 사용할 수 있는 기능들에는 적용하지 않겠습니다.
• 백엔드 코드 내 예외 ⇒ LoginException
• 에러 코드 구분할 것 없이 401 Unauthorized
  • 아이디가 없는 경우, 아이디는 맞는데 비밀번호가 틀린 경우 구분하지 않습니다.
  • 인증이 만료된 경우, 인증이 valid 하지 않은, 권한이 없는 경우 역시 구분하지 않습니다.
  • 클라이언트에서는 그냥 로그인이 되지 않았다는 것만을 사용자에게 알려주고, 로그인 페이지로 redirect하면 될 것 같습니다.

✔️ 점역 관련 에러

• 크게 외부 API 호출에서 예외가 발생한 경우, 그리고 백엔드 서버 내 파일 처리에서 예외가 발생한 경우로 나눌 수 있습니다.
  • 외부 API 호출 TranscriptionException
    • OCR에서 예외가 발생한 경우
    • 점역 알고리즘에서 예외가 발생한 경우
  • 백엔드 서버 내부 FileException
    • 파일 처리에서 예외가 발생한 경우
• pdf 파일 처리 과정에서 에러 발생 ⇒ 500 Internal Server Error error code=P
• OCR API 호출 과정에서 에러 발생 ⇒ 500 Internal Server Error error code=O
• Latex 파일 처리 과정에서 에러 발생 ⇒ 500 Internal Server Error error code=L
• 점역 API 호출 과정에서 에러 발생 ⇒ 500 Internal Server Error error code=T
• brf 파일 처리 과정에서 에러 발생 ⇒ 500 Internal Server Error error code=B