본 포스팅은 31기 SOPT 3주차 생각 과제입니다.
개요
3차 세미나 도전 과제를 수행하면서 뷰를 보고 어떤 데이터가 내려주어야 할까에 대한 고민도 있었지만, URI를 어떻게 설계해야할 지, RESTful한 설계는 어떤 것인지에 대한 고민이 있었습니다. 이러한 궁금증으로 GET Method를 통해 데이터를 넘길 경우를 생각해 Path Variable과 Query Parameter에 대해서 알아보고자 3주차 생각 과제 주제로 가져오게 되었습니다. 이 내용을 바탕으로 어떤 상황에서 활용하면 좋을지와 URI를 설계 시 고민해볼 부분들까지 함께 간단하게 정리해보도록 하겠습니다.
내용
Path Variable
Path Variable은 말 그대로 경로를 변수로서 사용하는 것입니다.
3차 세미나 도전 과제와 같이 넷플릭스에는 여러가지 콘텐츠들이 존재하고 각각의 콘텐츠를 볼 수 있는 경우를 생각해볼 수 있겠습니다. 그럴 경우에는 각 콘텐츠의 id를 받아서 넘겨줘야 하고 그렇다면 우리는 다음과 같이 경로를 작성할 수 있습니다.
/contents/:contentId # ex. /contents/123127Query Parameter
Query Parameter 은 경로 뒤에 입력 데이터를 함께 제공하는 식으로 사용합니다. ?이후의 부분을 query string이라고 합니다. Path Variable에서 언급했던 경우를 Query Parameter로 작성한다면 다음과 같이 작성할 수 있습니다.
/contents?contentId= # ex. /contents?contentId=921그리고 파라미터가 여러 개일 경우에는 &를 사용하여 여러 개의 파라미터를 넘길 수도 있습니다.
엔드포인트주소/엔드포인트주소?파라미터=값&파라미터=값어떤 상황에서 적합할까?
우리가 어떤 자원의 위치를 특정해서 보여줘야 할 경우 Path variable을 사용하고 정렬, 필터링, 검색, 페이징을 통해 보여줘야 할 경우에 Query parameter를 사용합니다. 아래는 이를 간단하게 적용해본 사례입니다.
/contents/movies/:movieId
/contents/dramas/:dramaId?episode=위와 같이 URI에 자원을 명사로 표현하고 GET과 같은 HTTP Methods를 통해 자원에 대한 행위를 표현해주면서 RESTful한 설계가 가능해지는 것이며, 이러한 방법은 모범 사례로 대부분의 개발자들이 권장하고 있는 방법이라고도 하네요
혹시나 적용하기가 어렵다면
알고 있는 것, 익숙한 것과 이해하고 직접 적용해보는 것은 또 다른 느낌이라고 생각해요! 당장 도전 과제에서 생각해보면 자원의 위치를 특정한다는 것이 명확하게 무슨 의미인지, 에피소드라는 데이터를 어떻게 표현해주어야 할지 등등 말이지요 (왜냐하면 제가 그랬거든요)
그래서 제가 파트장님을 괴롭혀서 코드리뷰를 받아냈습니다! 하하
이해하기 쉽도록 리뷰를 달아주셨고 또 충분히 고민해볼 부분도 함께 제시해주셨으니 여러분들에게도 많은 도움이 될거 같아서 공유드립니다:)
마치며
API를 설계함에 있어서 정답은 없다고들 하지만 충분히 효율적이고 더 나은 방법은 존재한다고 생각합니다. 우리는 혼자서 개발을 하는 것이 아니니 위와 같은 내용의 모범 사례와 실제 사용하고 있는 서비스의 라우트를 검색해보고 적용해보는 것이 다른 사람들과의 협업, 그리고 유지보수 측면에서 효과적이라는 생각이 듭니다. 혹시 RESTful에 대해서 더 알고 싶은 분들은 그런 REST API로 괜찮은가?를 참고해보면 좋을 거 같아요!
참고
