Path Parameter와 Query Parameter에 대해서 생각해보기
최근에 새로운 조직에서 업무를 하고 있습니다. 기술 스택도 다르고, 팀 컨벤션 관련해서는 정말 많은 학습을 하고 있습니다.
팀 컨벤션을 하면서 기존에 REST API에 절여진 생각에 대해서 고민하게 되었다. 특히 여러가지 면으로 고민을 해보게 되는데, 그 주제 중 하나인 Path Parameter와 Query Parameter에 대해서 생각하게 되었다.
GET Method를 사용할때 일반적인 REST API로 구현을 하면 아래와 같다.
GET /memo/1Rest api의 보편적인 패턴인 위 방식을 팀 컨벤션에서는 Path Param이 가독성이 떨어진다고 Query Param 만을 사용해서 API를 개발하라고 명령했다. 이유로는 보편성(공개할 API X)이나 SEO를 고려하지 않는 API이기 때문에 의미가 없다고 알려주었다.
위 코드를 명령한대로 바꾸면 아래와 같다.
GET /memo/?id=1위를 했을때 장단점이 무엇일까? 이를 여러가지 방면에서 비교를 해보자.
가독성
가독성의 기준은 상당히 주관적이다. (인간의 심리학과 인문학에 대해서는 넘어가자)
/memo/1 vs /memo?id=1 로 하였을때 가독성 면으로 질문을 해보았다. 회사에서는 후자가 많이 나왔다.
그래도 의문이 생겨서 다양한 회사에 다니는 다양한 연차의 개발자인 불특정 다수의 오픈채팅방에 논의해보았다. 그리고 전 회사 사람들에게도 물어보았다.
한 명을 제외한 8명이 왼쪽을 택했다. 이유는 보기에 따라서 단순하고 대부분의 개발자가 Rest API 형식으로 점이었다 친숙하나는 점이였다. 또한 상대적으로 짧기 때문에 가독성이 더 있다는 것이다. (단순한게 좋다같은 이야기.. 누구는 용량적으로도 이득이지 않냐고..)
오른쪽을 택한 사람은 1이 뭐를 의미하는지 알 수 있어서라는 이유였다.
아마 전자가 가독성은 더 있다고 판단된다.
Path Param과 Query Param의 차이
위 분류의 차이는 무엇일까에 대한 논의가 많이 나왔다.
많은 논의를 여러 개발자와 거쳤고 require(Path param) vs optional(Query param)의 차이라고 결론이 나왔다.
한편, 백엔드 웹 프레임워크는 위 예제로 Path param으로 구현할때 1값이 없는 경우에는 지정하지 않는 url이라서 status code를 404를 반환하여서 프로토콜(규약)의 의미에 적합하게 사용한다. (몰론 규약에 의미있게 사용하는거랑 각 회사의 상황에서 도움이 되는건 차이가 있다.)
기능적으로는 path와 query를 잘 이용했을때 SEO의 의미가 있다. query보다 path가 한편으로 SEO가 더 잘된다고 한다.
공식 문서에서는?
한편 RFC 규약에서 URI에는 Resource는 Path에 등록할 것을 약속으로 명시하고 있다. Resource(자원)이라는 것이니 자원으로 처리하며 Query Param은 계획과 권한 밖에 있는 경우에 사용하는 것을 정의할때 명시하고 규약이 적혀있다.
위 내용으로 따졌을때, Query Param은 Filter용이라는 느낌을 받았고, Path는 필수 자원이라는 느낌으로 이해가 되었다. (이 말이 되게 묘한거 같다.)
필수로 요구되는 값과 관련있을 때는 Path Param을 사용하고, 필수가 아니고 옵션일 경우에는 Query Param을 추천한다.
다만 팀에서 SEO와 Protocol 규약을 고려하지 않고 컨벤션으로 가진다면 이를 지키지 않아도 무관하다.
개인적으로 뭔가 내가 당연하다고 생각하는 것에 대해서 의문을 가질 수 있어서 좋은 경험이였다. 배울점이 많은거 같아서 좋은 조직이라고 생각한다.
