필요한 API들을 나름 restful하게 만들려고 노력했던 것 같다. 점점 API들이 추가됨에 따라 아래와 같은 고민들이 생겼던 것 같다.
- 비슷한 API들의 증가
- nested url을 써야하는가? 새로운 라우터로 분리하여야 하는가?
고민
/v1/stores/:storeId/orders, /v1/users/:userId/orders와 같은방식으로 가게 토큰으로 사용할 수 있는 해당가게의 주문 내역 조회와 고객토큰으로 사용할 수 있는 고객의 주문내역조회 API를 만들 수 있도록 제작했었다. 그리고 관리자토큰으로 사용하는 전체주문내역조회 API/v1/orders도 있었다.
주문 내역을 조회할 수 있는 API가 총 3가지가 생긴 것이고, 각각이 응답하는 데이터들도 조금씩 달랐다. 그러다보니 어떤 API를 사용해야하는지 명확하지 않았던 것 같다. 어떻게보면 가게의 주문, 고객의 주문, 전체주문이라는 기준이 있긴 하지만, 이런 류의 API들이 계속해서 늘어나게 될 경우, 점점 어떤 API를 사용해야하는지 알기 힘들것 같다고 느꼈다.
왜냐하면, 현금영수증을 조회한다고 했을 때, 전체 현금영수증 처리 내역, 고객별 현금영수증 처리내역, 가게별 현금영수증 처리내역도 나눌것인가? 와 같은 문제들이 이어졌기 때문이다.
그렇다고 하나로 두었을 경우, 토큰별로 storeId나 userId를 쿼리스트링에 필수적으로 넣도록 강제해야했다. 또는 고객용, 가게용, 관리자용 API를 분리함으로서 해결가능할 것이란 생각이 들었다. 그치만 너무 많은 수정을 필요로 하는게 아닐까란 생각이 들었다.
결과
결과적으로 일단 두었다. 그리고 추가적으로 생성되는 API들은 충분히 고민해보고 분리가 가능하다면 새로운 라우터로 분리하는 방향으로 제작했다.
(ex. 주문환불 API는 별도로 라우터를 두었다. 왜냐하면 주문환불 내역에 대한 조회 또는 환불 취소, 코멘트를 작성하거나 환불계좌를 수정하는 요구사항들이 있을 것인데, 주문 라우터 하위에 둘 경우, API가 너무 길어지게 되고 유연하지 못할것이라 생각했다.)
nested url을 사용함으로써 명확한 리소스간의 관계를 파악할 수 있겠지만, 이외에 수정이나 변경 N+1 Problem등을 고려할 때, 오히려 루트 리소스를 여러가지 가지고 있는 것이 수정에 좋을 것이라 생각한다.
느낀점
앞으로 API를 만드는데 있어서 무지성으로 짜는 것이 아니라, 어떻게 하면 확장하기 편할지, 그리고 다른 개발자들이 확인했을 때, 쉽게 이해되고 사용할 수 있을지에 대해 고민하며 만들어야겠다고 느꼈다.
