12/16 TIL | 쉼표 작업 일지 #6. F/E URL 설계. '리소스'를 생각할 것!

🔙 이전 시리즈

12/15 TIL | 쉼표 작업 일지 #5. 사용자 스토리 작성.

---

오늘 작업 목표 달성률(40%)

✅ F/E URL 설계
🟩 인수 테스트 작성(작업 중💬)
🟩 REST API 및 Backdoor API 설계 

작업 회고

오늘은 드디어 프론트엔드 URL 설계를 하였고, 인수 테스트를 작성하는 중이다. 역시나 범위가 큰 만큼 인수 테스트 시나리오 또한 마카오 기프트샵이랑 차원이 다르게 많고, 더군다나 기획이나 요구사항이 명확하지 않은 상황이라 작성하는 속도가 많이 더딘 상황이다.

좌) 카테고리 페이지 / 우) 각 카테고리 상세 목록 페이지

페이지도 많다 보니 프론트엔드 URL 설계 역시나 어려웠는데.. 위 카테고리 페이지에서 각 카테고리를 클릭하게 되면 각 카테고리에 해당하는 프로그램 목록들이 반환하는 페이지가 등장하는 상황에서

1. /categories?category=temple
2. /categories/temple

문득 쿼리 스트링을 사용한 1번 페이지와 2번 페이지 둘 중 어떤 것이 맞는 설계인지 고민이 되는 것이다.. 하여 아샬님께 질문을 남겼고, 아샬님께서 주신 답변은 '리소스를 생각해라'였다. 이 페이지 링크 리소스는 프로그램 그러니 /programs?category=temple 또는 /categories/temple/program가 되어야 한다는 것이다.

그렇게 따지고 보니 아차 싶었던 게 프로그램을 클릭했을 때 이동하는 페이지는 /programs/{id}이면서 막상 >>카테고리<< 페이지라는 것에 매몰되어 궁극적인 리소스인 programs를 바라보지 못했던 것이다.. 무튼 아샬님의 답변과 홀맨님의 조언 덕분에 프로그램 카테고리 별 목록 페이지는 /programs?category={category}으로 URL을 확정할 수 있게 되었고 그리하여 완성된 URL은 아래와 같다.

쉼표 F/E URL

F/E URL 설계를 하면서 어려웠던 점은 계속 이걸 REST API 설계와 연관 지어서 생각하게 된다는 것이다. 하지만 페이지 URL은 하나의 리소스로 규정되기 어려운 경우가 많기 때문에 화면과 UX 중심으로 생각해야 한다. REST API의 GET /programs와 달리 하나의 페이지에서 여러 가지의 리소스를 GET하기 때문! 결론은 두 가지 입장을 모두 고려해야 하고 관심사의 분리가 이루어져야 한다.

지난번에도 주셨던 피드백과 동일한데 작업을 하다 보면 계속 프론트 혹은 백, 한쪽에 치우친 생각을 하게 된다...🥹 이번에도 역시나 그랬고.. 앞으로는 질문하기 전에 제발 내가 양쪽을 모두 고려한 후에도 내리지 못한 결론인지를 확인하기 질문을 하자!