Frudy
6k
2020-11-21 12:41:42 작성 2020-11-21 13:16:24 수정됨
6
688

HTTP 상태코드 대신 임의 에러코드를 사용하는 경우 생기는 문제점


안녕하세요. 


회사에서 개발하며 생긴 경험을 공유하고자 글을작성하게 되었습니다.


다른분들께 참고가 되었으면 좋겠습니다!

혹은 다른 의견이 있다면 같이 공유 부탁드립니다. 저도 모르는게 많아요.


상황 : 게시글번호가 1번인 게시글 1개 가져오는 API 만들기


방법1. Http Stats Code로 구현하는 방법 (제가 제안하는 방법)


방법2. Custom Error Code로 구현하는 방법 (회사 방법 & 개발팀장님이 지시?하신 방법)

(1) 모든 요청은 POST로 해야하고

(2) 모든 응답은 반드시 HTTP 상태코드를 200으로 응답해야하고

(3) 모든 응답에는 추가로 이렇게 별도의 에러코드를 응답하고있습니다.

(* 실제 회사에서 작성돤 API의 응답은 위와 다르며, 위 응답 캡처는 예시를 들고있습니다.)



뭐 제가 모르는 차이점도 있겠지만, 제가 체감했던 차이점은 아래와 같았습니다.


1. 표준화 정도의 차이

(1) HTTP 상태코드는 세계 표준이라고 생각해요.

전세계 모든 웹개발자는 404가 Not Found 성격이라는걸 알고있을거에요.

응답에 404가 떨어지면, Not Found라고 이해할거에요.


(2) Custom Error Code는 회사 내에서 정한 표준(?) 음.. 약속 이라는 표현이 맞겠네요.

- 저희회사 개발자가 아니면 ERROR_1 이라는 응답이 뭔뜻인지 모를거에요.

- 만약 추후 개발인원이 바뀌어서 새로운분이 들어오면 이부분에 대해 추가 인수인계를 받아야겠죠?

- 즉 에러코드에 대해서도 유지보수 비용이 발생해요.


사실 제일 큰 문제는 회사 내 개발자도 ERROR_1이 뭔뜻인지 까먹기 쉬워요.


사이트 A에서 쓰는 API 만들 때는 ERROR_1이 404라는 뜻으로 쓰고 있었는데

사이트 B 에서 쓰는 API 만들 때는 ERROR_2가 404라는 뜻으로 쓰이고있다던가,


ERROR_1을 404라는 뜻으로 쓰기로 약속했는데

요청을 보냈더니 ERROR_2가 발생하길래 봤는데 해당 번호로 게시글이 없는 경우라던가...


API 명세서에는 ERROR_1이 없는 게시글의 경우에 발생한다고 표기되어있는데

클라이언트 에서는 ERROR_2가 발생하면 "없는 게시글입니다" 라고 안내하도록 구현되어있고

그래서, 또 다시 에러코드에 대해서만 정리된 별도의 문서가 또 존재합니다.


=

1. API명세서

2. 실제 구현된 클라이언트 측 소스코드 + 주석

3. 에러코드에 대해서만 정리된 별도의 문서


에러코드 하나때문에 유지보수 해야하는게 3가지가있네요.

실제로 이 3가지가 서로 말이 또 다른경우가 잦습니다.


ㅡㅡㅡㅡ


이 방법에 대해 팀장님이 안내해주실 때,

"이렇게 구현하는게 편하다" 라고 하셨어요.


const res = await axios.post('http://localhost:3000/notice/1');

if (res.data.errorCode === 'ERROR_1') {
// 없는 게시글입니다 라고 안내
}

if (res.status === 404) {
// 없는 게시글입니다 라고 안내
}

위와 아래의 코드는 아무런 차이가 음...없다고 생각하는데

제가 생각하지 못한 부분이 있을까요? 


제가 보기에는 구현난이도에는 차이가 없다고 생각해요.


뭐 어쨌든,

 HTTP 상태코드와, 임의 에러코드 2가지에 대해 생각해볼 수 있었던 계기가 되어서 좋았습니다.


물론 이런경우는 저도 납득하고있습니다

1. Http Status Code만으로는 정확하게 에러원인이 뭔지 알 수 없을 떼 구체적인 에러를 안내하기 위함


이 1가지말고는 생각나는 이유가 없습니다.

이 상태에서, REST API가 뭔지 공부해보면 좀 더 많은 비교를 할 수 있을거에요.

1
  • 댓글 6

  • devcrema
    1k
    2020-11-21 15:56:56

    코드로 보자면 아래 코드가 훨씬 안전합니다.

    status code는 어떤 상황에서도 들어오지만 위 에러 data는 상황에 따라서 보장되지 않습니다.

    만약 핸들링 되지 않은 에러가 운나쁘게 internal하게 발생할 경우, 위의 코드에서는 언제든지 클라이언트에도 장애전파가 될 수 있죠.

    안전성 이외에도 표준을 따라가지 않는 것에 따른 가독성도 큰 영향이 있구요.

    ERROR_1이라고 한다면 누가 봐도 의미전달이 안되서 유지보수를 크게 낮추고 의사소통 비용만 증가하는 결과로 보여지네요.

  • Frudy
    6k
    2020-11-21 16:47:25 작성 2020-11-21 16:52:41 수정됨

    devcrema

    맞아요.


    비유하자면

    response data에 errorCode가 아니라, errorCodo 라는 이름으로 데이터가 온적이 한번 있었어요.

    오타죠.

  • ISA
    3k
    2020-11-22 15:32:52
    애초에 모든 요청의 메소드를 post로 한다는거 부터가 rest api 설계가 아니기에 뭐라 말하기 힘드네요.
    한번 이건 무슨 설계 방식인지 물어보시는게 좋을거 같아요. 아키텍쳐상 rest api 구현이 목적이라면 하나부터 다 잘못된 방식입니다.
  • 콘푸로스트
    1k
    2020-11-23 10:34:15

    팀장님 말이 맞다고 봅니다.

    상태코드 404도 해야하고, 별도의 에러코드 error_1도 사용해아하구요.


    서버 내 에러가 발생한다면

    try catch문이 없다면 500, 503으로 응답받아서 서버오류를 표기하겠지만

    try catch문에서 서버 에러를 처리한 경우에는 상태코드 정상 200으로 응답해줍니다.


    별도의 에러코드로 처리하는게 맞다고 봅니다.

    파일 용량 때문인지, 파일 확장자 때문인지, 혹은 또 다른 이유인지 적절한 오류 메시지로 사용자에게 보여주는게 맞다고 봅니다.

  • fender
    19k
    2020-11-23 19:22:43

    다른 고려사항으로는 모니터링이 있습니다. 서비스가 정상 동작하는지 감시하기 위한 모니터링 도구는 모두 HTTP 비정상 응답 코드를 지원하겠지만, 커스텀 오류 코드의 경우 지원을 하지 않거나 하더라도 동작이 보다 비효율적일 수 있습니다.

  • Frudy
    6k
    2020-11-23 19:26:33

    오..... 그거는 처음들어보네요.

    감사합니다.

  • 로그인을 하시면 댓글 을 등록할 수 있습니다.