아래 내용을 ChatGPT 에 입력해서 공방전(?)을 펼쳤는데, 내 표현에 생략된 부분이 너무 많다는 것을 알게 되었다. 좀 더 정확한 주장은 다음과 같다.
- 비지니스 로직에서 4xx, 5xx 를 리턴하는 것은 무의미하다. (2xx, 3xx 만 활용하자)
- GET, POST 외의 HTTP methods 는 사용할 필요가 없다.
대화 전문: https://chatgpt.com/share/683b0b3b-fca4-8012-9aaa-dd122b80d324
혹시 안보일 때를 대비한 전문 캡쳐: https://drive.google.com/file/d/1FgWgJI8J75lsa7D9aPqPu8Z6BwGikO-Q/view?usp=sharing
json rpc 에 대한 설명은 공식 홈페이지에 잘 나와있으니 생략하겠다.
왜 http status code 를 준수하지 말아야 하는가, 라고 생각해보면 이게 표준을 쓴다는 뿌듯함 외에 별다른 장점이 없기 때문이다.
RESTful API, HTTP status code 가 쓸모없는 이유
- 프론트에서 처리할 때 한 번 더 고려해야 한다.
XHR, fetch, axios 등에서 4xx, 5xx 는 catch 문으로 떨어지기 때문에, 이에 대한 response body 처리를 별도로 해야 한다.
- network 레벨에서 비지니스 에러와 시스템 에러를 구분하기가 힘들어진다.
4 Layer 부근의 에러를 모아볼 수 있는 기회를 날려버리는 꼴이다.
- 해석이 굉장히 분분하다.
'빅' 테크 회사들이 여전히 동일한 에러에 동일한 응답을 주지 않는다. 즉, 우리 모두 여전히 401과 403의 차이를 "해석" 해내야만 한다.
- RESTful, status code 는 '비지니스'를 전혀 반영하지 못한다.
RESTful API 에 대해서: 이것은 '리소스'의 관리에 대한 얘기지, 나의 '사업'을 설명하는 도구가 아니다. 사업은 '리소스'들의 결합으로 보기엔 너무나 복잡하고 다층적인 것이다. 생성, 조회, 수정, 삭제는 빙산의 일각일 뿐이다. 복제, 사용, 전달, 거부, 업그레이드는 어떻게 표현할 것인가? POST 나 PATCH 를 쓰면 될 것 같은가? 왜 내가 HTTP method 를 고려해야 하는데? 난 비지니스를 구현하고 싶은 것이지 RESTful 한 API 를 짜고 싶은 것이 아니다.
HTTP Status code 에 대해서: 백엔드 개발자 중, 실무에서 프론트엔드 개발자가 "status code 를 명확하게 보내주세요. 200, 201, 301, 302, 307, 308, 400, 401, 403, 409, 429, 500, 502, 503, 504를 딱딱 케이스에 맞춰서 보내주셔야 합니다"라고 얘기하는 것을 한 번이라도 들어분이 있으신지? 나머지는 위 항목과 동일하다. status code 는 비지니스 에러와 1:1로 대응이 되지 않을 뿐더러, 인프라/네트워크 레벨에서의 불필요한 운영 리소스를 요구한다.
대안이 있는가
일찍이 (그리고 당연히) 이런 생각은 나만 한 것이 아니다. 모든 응답이 GET/POST, 2xx/5xx 으로만 리턴되는 경우가 내 앞 세대에 많이 있었던 것으로 보인다 (5xx 은 전혀 의도가 아닌 상황임). 왜 그 자리를 위 기술들이 이겼는지 그 과정은 잘 모르겠다.
jsend: https://github.com/omniti-labs/jsend
json-rpc: https://www.jsonrpc.org/specification
이런 기술들로 대안을 고려해볼 수 있다.
결론
내 생각에, http status code 에 관심있는 집단은 적어도 B2C 엔터프라이즈는 아니다. 모두가 '어느정도' ('완벽히'도 아님) 이해하고 있어서 초기의 고민을 줄일 수 있다는 것 외에는, 쓰면 쓸수록 이상한 곳에 고민을 하게 만드는 안좋은 기술들이다.
여담
다시보니 그냥 gRPC 예찬론이잖아 이거
부록
내 의견을 지지하는(것 처럼 보이는) 글들
내가 동의하지 않는 글들:
