배경
API 설계시 일부 기업이나 방법론 중 모든 상태 코드를 200으로 처리하는 방법이 종종 거론되곤 한다.
관련 링크 : https://okky.kr/questions/661303 (카더라긴 하지만 댓글에 기타 정보 내용이 있음)
일반적으로 응답 코드는 요청에 대한 상태를 나타내는 HTTP 상태 코드(Status code)와, 에러에 대한 정보를 담은 세부 에러 코드(Error code)로 나뉘며
일반적인 처리는 상태 코드별로 > 세부 에러 코드를 나누는 것이 일반적이다.
위에 말한 방법은 상태 코드를 통일하고 > 세부 에러 코드로 통합 하는 것 이다.
모든 상태코드를 200으로 고정하여 처리 하는 경우
주된 목적 : HTTP Status Code가 노출 될 시 보안에 위험이 있을 수 있음 (ex. 정부 시큐어 코딩 내용 중 공격자가 상태 코드를 통해 정보를 얻을 수 있다는 이유
특징
- 기존에 일부 상태코드를 200으로 처리 (ex. 200, 204, 400, 401, 403, 404, 500등..)
- 502, 503 일부 상태 코드에 대해서는 웹 어플리케이션 뿐 아닌, 웹 서버 레벨에서의 처리도 병행되어야 함 (ex. Nginx)
- 모든 영역 (인프라, 서버, 앱 등)에서의 처리에 보다 적절한 경우지 않을까 하는
- HTTP 프로토콜 표준에 맞지 않으며, 다양한 외부 연동시에 충돌이나 복잡도가 높아질 가능성도 있음
실제 사용하는 기업
결론
상태코드를 지키며 HTTP 표준 대로 하는 방법이 제일 좋은 것 같다.
기본적으로는 상태코드 (200, 400, 401, 500 등 구분하고) 필요시 Header나, Body등을 통해 세부 정보를 더 보내주는 것이 낫지 않나 싶다.
만약 현재 프로젝트에서 200을 통일하여 쓰고 있는데.. 수정이 어려운 경우.. 다음 프로젝트 부터는 바꿔보는 것을 지향하는 걸로
기타 참고문헌
'소프트웨어 개발자 > 좋은 API, DB 설계하기' 카테고리의 다른 글
[좋은 DB 설계하기] 제한된 값을 설계 할 때 Enum vs 테이블 (0) | 2024.07.05 |
---|---|
[좋은 DB 설계하기] 테이블 명 설계 비교 (_log, _results, _history) (0) | 2024.06.30 |
[좋은 API 설계하기] API 버전 정책 (feat. 토스페이먼츠) (0) | 2024.01.31 |
[좋은 API 설계하기] 조회 한 데이터 없음 - 상태코드 200? (0) | 2024.01.31 |
[좋은 API 설계하기] 응답 Schema 의 Null 값 처리 (0) | 2024.01.31 |