API 호출 시, 응답의 반환하는 방법에 대해 질문이 있습니다.

Question

제가 했던 방식과 다른 새로운 방식을 알게 됐는데 다른 개발자분들은 일할 때 어떤 식으로 통신하는지 궁금증이 생겼습니다. 그리고 이번 기회에 다른 개발자들과 이야기해 보면서 또 어떤 방식이 있는지 알기 위해 커리어리에 첫 글(질문)을 쓰게 됐습니다.

——
***들어가기 전에***
- 신입 백엔드 개발자로 취업 준비 중입니다.
- 다양한 방식으로 해보는 걸 좋아하기 때문에 장단점만 있을 뿐 정답은 없다고 생각합니다.
- API 요청 시, `Reponse status code`는 클라이언트-서버와의 약속이라고 생각하고 있고, 약속을 했으면 따라야 한다고 생각합니다.
- 기간이 짧은 프로젝트이기 때문에 어떤 답변이 오더라도 프로젝트에서 정한 약속을 바꿀 생각은 없습니다. 프로젝트가 끝나고 백엔드 개발자분과 리팩토링을 하면서 의견을 공유해보고 싶긴 합니다. (원하지 않는다면 어쩔 수 없고요..)

***중요***
- 글을 잘 쓰는 편이 아니라 이해가 안되거나 제 말투가 공격적이라고 느껴지는 부분이 있으면 언제든지 말씀해 주세요!
- 만약 방식이 잘못됐다고 생각하시면, 그렇게 생각하는 이유와 가능하다면 경험을 공유해주세요!

——
# 본문
지금까지 RFC / MDN / IT 기업 기술 블로그 등을 보고 REST API를 공부했고, 설계 원칙에 따라 모든 API 요청에 대한 Response 상태 코드를 200, 400, 401, 403, 404, 500 등과 같이 정확하게 주고받아야 한다고 생각하고 있었습니다. (물론 애매한 경우도 있었습니다)
그런데 최근 짧은 기간 동안 프로젝트를 하게 되었는데, iOS 개발자(2년차 현직)분과 백엔드 개발자(신입 개발자 취업 준비)분께서는 아래와 같은 의견을 주셨습니다.

클라이언트의 입장에서 요청을 보냈을 때, 서버와 연결이 실패한 게 아니라 서버를 통해 정의된 에러 (4xx, 5xx)를 받았으니 통신에 성공한 것이다. 그러므로 API의 모든 요청(권한이 없는 사용자의 요청, 잘못된 리소스 요청, 이미 가입한 사용자가 다시 회원 가입 요청 등)의 `Response status code`는 200을 반환하고 body에 서버에서 응답한 상태 코드(3xx,4xx, 5xx 등)와 함께 커스텀으로 명시한 에러 코드(AUTH-001 등), 에러 메시지를 보내야 한다.

관점을 다르게 보면 그럴 수 있겠구나 싶었고 문득 주변 개발자분들은 어떻게 구현을 하는지 궁금해져서 이야기를 나눠봤는데 그 결과는 반반이었습니다. 아직 그분들도 연차가 높지 않기 때문에 그렇게 설계한 이유와 이점에 대해 자세히 알고 계시지는 못했습니다.

——
# 질문
1. 모든 요청의 Response status code로 200을 보내는 건 REST API 설계에 어긋난다고 생각하는데 이렇게 설계하는 이유와 있는지 궁금합니다.

2. 모든 API 요청의 Response status code를 200으로 보내는 방식으로 구현한다면 나중에 어떤 문제가 생길 수 있을까요? (예를 들어 웹으로 확장 등)
  - 현재 iOS로 개발 중이며, 확장 가능성은 없는 상태입니다. 단순하게 궁금해서 질문드립니다.

3. 만약 두 방식 외에 다른 방식으로 통신한 경험이 있으시면 그 방식을 선택하신 이유와 이점도 궁금합니다.

백승훈 · Accepted Answer

안녕하세요 답변 드립니다 😏

1번 답변의 경우 일반적으로는 RESTful Api로 설계하는게 가장 이상적이긴 합니다. 다만 200으로 통일하여 설계하는 주된 이유는 클라이언트 개발자가 HTTP 상태 코드를 처리하는 대신, 응답 본문에서 커스텀 에러 코드를 사용하여 더 세분화된 에러 처리를 하고자 할 때입니다.

예를 들어 같은 401 에러라고 하더라도 토큰을 비활성화 할것인지 재요청 할것인지 특정 모달이나 팝업을 생성&취소할 시 결국 내부에 더 상세한 에러코드를 넣고 분기처리를 해야하는 경우가 있습니다. 조금 더 복잡해질 경우

401
1. 앱종료
2. 재요청
3. 팝업 1번타입 요청
4. 확인창 3번타입 요청

4가지 타입이 있다고 가정할 때

200에서도
1. 앱종료
2. 재요청
3. 정상팝업처리
4. 팝업 1번타입 요청
5. 팝업 3번타입 요청
6. 확인창 3번타입 요청

이런식이라고 가정한다면 200에서 6가지 분기처리 401에서 4가지 분기처리를 따로 태워야 합니다.

하지만 자체 상세코드를 통히 각 타입을 분류해서 (앱종료는 G001) 200으로 통일한 상태에서 클라이언트(유저)에게 어떤 걸 보여줄지 명세할 경우 분기처리나 보여줄 팝업내용등을 일관성있게 유지할 수 있습니다.

하지만 이러한 방식이 무조건 좋지는 않습니다. 새로 합류하는 개발자가 보기에는 오해의 여지가 있을수도 있고 이후 유지 보수에서 잘못된 오해를 만들 수도 있습니다.

결론적으로는 상황에 따라 둘 다 있을 수 있다고 생각합니다. 일반적으로는 REST API를 맞추는게 더 적합하다고 생각하며 경우에 따라 에러나 커스텀한 예외처리가 많을 경우 차라리 200으로 통일하고 내부 에러코드를 통해 컨트롤도 가능하다고 생각합니다.

3번 질문의 답으로는 그래프 QL같은걸 들어볼 수 있겠내요 GraphQL을 사용하는 경우, GraphQL은 오류 처리를 위해 errors 필드를 사용하여 API 응답에 오류 정보를 포함할 수 있습니다. 이는 클라이언트가 오류를 더 세밀하게 처리할 수 있게 해주며, HTTP 상태 코드와는 다른 차원의 유연성을 제공합니다