HTTP status code는 어떻게 전달하는 것이 좋을까

고민상황 

프로젝트를 진행하면서 프론트 - 백엔드 사이에 여러가지 이슈가 있었지만, 가장 많이 얘기가 나왔고, 팀원들 스스로도 중요하게 생각한 부분이 "어떻게 HTTP Request - Response를 주고 받을 것인가" 이었다.

 

프론트 팀원들이 Response를 받은 후 어떻게 처리를 하느냐에도 영향을 미치기도 하며, 어떻게 하면 Restful 하게 이를 설계하고 구현할 수 있을지에 대해서도 고려해야하기 때문에 이러한 부분들이 주된 고민을 이뤘던 것 같다. 

이번글에서는 그중에서, HTTP 응답 상태코드 (status code)에 대한 고민을 기록해보고자한다. 

 

개발 및 프로젝트를 하다보면, 여러가지 상태코드(2xx, 4xx등) 를 사용하여, 성공/실패 여부, 성공/실패했다면 어떤 이유로 성공/실패 했는지를 알 수 있게 된다. 

 

다만, 이러한 상태코드를 어떻게 반영할지에 대해서의 방법은 크게 2가지가 있었고, 

위 방법들에 대한 장/단점 및 실제 서비스에서는 어떻게 구현이 되었는지 찾아보았다. 

 

1. HTTP Status Code

말그대로 HTTP status code에 반영을 하는 것이다. 

 

장점 

- Restful하게 API를 설계 및 구현할 수 있다. 

- 클라이언트에서 Response를 받는데, 상태코드만으로 Response를 구별할 수 있으며, 비즈니스 로직 작성에 유용하다. 

 

실제 구현 참고 

위의 그림 처럼 카카오에서는 HTTP status code에 반영한다.

https://developers.kakao.com/docs/latest/ko/reference/rest-api-reference

 

2. HTTP status code 200 고정, body를 이용

...

해당 방법은 HTTP status code로 200을 통일하여 사용하고 이는 '정상적으로 응답했다'라는 것을 알려준다. 

실제 status code는 body안에 포함시킨다. 

 

장점 

가장 큰 이유는 보안적인 이유이다. 

 

- HTTP status code에 200이 아닌 4xx, 5xx 코드를 넣을시 해당 코드가 공격자에게 노출이 된다. 이는 공격자에게 '에러 발생 조건'을 판단할 수 있는 가능성을 준다.

이는 다음과 같은 위험성을 야기한다.

 

1. 공격자가 오류를 발생시켜 서버 작동을 중지시킬 수 있다. 

2 서버에 있는 데이터 구조가 노출될 수 있다. 

 

단점 

하지만, 단점은 위에서 언급한 1번 방법을 통해 가져올 수 있는 장점을 갖지 못한다는 점일 것이다.

 

1. Restful하지 못하다. 2. 클라이언트 개발자가 status code만으로 response를 구별하지 못하며, response에 따라 비즈니스 로직을 구현하는 데에 있어서, Response Body에 있는 내용까지 찾아봐야한다. 참고로 진행하고 있는 프로젝트에서 클라이언트 팀원들이 이러한 피드백을 많이 주었다. 

 

실제 구현 참고 

쿠팡 웹 페이지에서는 2번 방법을 따르는 것 같았다. 

다음은 이미 가입되어있는 이메일을 입력하여 회원가입을 진행하고 있을때 개발자 도구를 통해 Response를 참고했는데, 

비즈니스 로직을 고려했을때 4XX대 코드가 나와야하지만, 돌아오는 상태코드는 200번이었고, 

 

Response Body 같은 경우에 4XX 상태코드는 없었지만, 

Enum type과 message를 통해서 충분한 정보를 Body에 담아서 보내주었고, 

추측컨데, 상태코드는 200이기 때문에, 이를 통해 구현할 비즈니스 로직을 구현할 수는 힘들 것 같았고, 

Enum type에 따라, 클라이언트 개발측에서 이를 쉽게 구별하는 것 아닐까 생각이 들었다. 

 

 

결론 및 프로젝트 적용 

해당 이슈의 구현은 장/단점을 비교하여 현재 프로젝트 상황에 필요한 선택을 하는 것이 적절할 것 같다. 

실제 레퍼런스를 참고했을때도, 무조건 이렇게 해야 정답이다라는 내용은 없었다. 

 

다만, 현업에 있는 개발자들의 글을 보니, 회사에서 정부 시큐어 코딩 가이드등 따라야하는 rule이 있다면, 그것에 따라서 개발하는 경우가 많았다. 

 

현재 내가 진행하고 있는 프로젝트 내에서는, 2번보다는 1번 방법으로 실제 status code에 반영하는 방법으로 결정하는 것이 현재 개발상황에 맞다고 판단이 들었고, 얻는 장점 역시 더욱 많다라는 점을 느꼈기에 1번 방법으로 구현하였다. 

 

저번 Get vs Post 관련 이슈에서도 https://minjun98.tistory.com/94

RESTful한 설계와 보안적인 이슈가 충돌하는 지점이 있었고, 이러한 부분이 고민되는 부분이었는데, 앞으로 어떠한 방법을 사용하더라도 위 두가지 고려사항을 생각할 필요가 있다고 생각이 들었다. 

 

https://potato-hyun.tistory.com/43

Server ) Api Http status code에 대하여, header와 통일시켜야할까 body에만 담아야 할까?

 

https://velog.io/@duf7040/REST-API-REST-API-status

[REST API] REST API 응답 상태

 

https://okky.kr/questions/661303

OKKY - 백엔드 개발자가 HTTP STATUS 코드를 항상 200 코드를 뿌려주는데 뭐라해야할지모르겠습니다