⌨️ 개인의 편리를 위해 규약을 느슨하게 해선 안된다
결론부터 말하자면 살짝 느슨해진 것 같다.
일을 하다 보니 어느새 귀찮은 것들에 대해 피하고 싶어 졌고, 그것이 곧 옳지 못한 구현으로 이어지기도 했다.
이 글은 그런 날을 돌이키며 기억해 두고 채찍질하기 위함이다.
🤔 쿼리스트링이 긴게 문제일까?
동료가 다른 일을 하는 동안 나는 작업하기 편하게 프론트를 조금 만져주는 걸로 일을 나누었다.
프론트에서 `Get` 요청을 보낼 때 쿼리스트링으로 만들어 주길 요청했으나.
나는 쿼리스트링이 너무 길어져서 불편해서 그런데 `Post`로 RequestBody에 담아도 될까요?라고 했다.
이런저런 이야기가 오고 갔지만, 결과적으론 쿼리스트링이 길어서 불편하다는 내 의견은 그냥
개인의 불편함을 호소하는 것뿐 합당한 이유가 되지는 못했다.
첫 회사에서 이런 동료를 만난 것은 내게 나름 큰 행운이 아닌가 싶다.
돌고 돌아 결과적으로 쿼리스트링이 긴 것은 문제가 아니다고 판단하기로 했다 (대부분의 경우)
✅ HTTP API를 Restful 하게 짜는 것
기본적으로 API 성숙도에서
Restful 하게 짜인 API는 메서드를 통해 그 행동을 나눈다.
조회엔 @GetMapping이 사용되는데, 기본적으로 @GetMapping은 RequetBody를 지원하지 않는다.
나는 개인의 불편함으로 우리의 API 성숙도를 낮추는 코드를 짤 뻔했다.
그 이유가 합당하다면 @PostMapping으로 변환할 수 있지만, 나의 경우는 그렇지 않았다.
✅ 쿼리스트링이 길어져도 문제가 없는 이유
1. 브라우저의 경우
쿼리 스트링이 매우 길어지는 경우 (2000자 이상)
가장 적게 지원해 주는 IE의 경우 약 2000자(2KB)까지의 쿼리스트링을 지원하는데
이를 넘어가는 쿼리스트링이 나가는 경우가 생긴다면..
고려해 볼 만 하지만 근본적으로 API를 분리하는 게 맞지 싶다.
그 외
Chrome : 2,000,000자 (2MB)
Edge : 2,000,000자 (2MB)
Firefox : 1,000,000자 (1MB)
Safari : 1,000,000자 (1MB)
2. 서버의 경우
- Apache는 8,192자를 기본값으로 하고 있고 LimitRequestLine을 통해 조절 가능
- Nginx는 8,192자를 기본값으로 하고 있고 large_client_header_buffers 설정을 통해 조절 가능
- IIS(MS Internet Information Services) : 4,096자를 기본으로 하고 maxUrl을 통해 조절 가능
3. 프로토콜
- HTTP/1.1 표준 자체에 URL의 길이를 제한하는 것이 명시되어 있지 않으므로 실질적으로 서버와 브라우저의 구현에 따라감
✅ 불편하다면 해결책이 있을 것
나의 가장 큰 실책이다.
프론트에서 쿼리스트링으로 보내는 것이 한두 번이 아닐 건데,
충분히 긴 쿼리스트링을 편하게 전환하는 방법이 있었을 것을 생각지 않고, 원래의 설계를 바꾸려고 했다.
URLSearchParams API를 이용한 방법
const queryString = new URLSearchParams(params).toString();
간단하게 끝난다. 애초에 params는 내가 보내주려고 했던 객체이고
이미 이러한 객체들을 queryString으로 변환해 주는 것은 기본적인 방법 외에도 많은 라이브러리들이 있었다.
결과적으로 내가 보내주기 위해 이미 만들어놓은 객체가 있는 이상
queryString으로 변환하는 게 귀찮다는 이유로 @PostMapping으로 변경하자고 요청하는 것은 잘못된 판단이었다.
❗결론
글 서두에 서술했듯이 개인의 불편함으로 규약과 초기에 설계한 약속을 어기는 것은 옳지 못하다.
그리고 그 원인이 명확한 근거가 아니라 개인이 지식의 부족이라면 더더욱이 말이다.
많이 아쉬운 하루였지만 반대로 경각심을 일깨워주고,
또 좋은 동료의 소중함을 알게 해 줘 다행인 하루였다.
