팀 프로젝트에서 URL 설계 실패를 교정한 경험 결
팀 프로젝트로 4명이 독서 기록 공유 서비스를 만들 때 처음으로 REST API 설계를 맡았습니다. 처음에는 URL 구조를 동사 중심으로 만들었는데(/getBook, /deleteBook), 프론트엔드 담당자가 "어디까지가 자원이고 어디서부터가 행위인지 헷갈린다"고 했습니다. 그제야 리소스 중심 설계가 왜 중요한지를 실감했습니다.
그 이후에는 HTTP 메서드(GET·POST·PUT·DELETE)로 행위를 표현하고 URL은 명사형 자원으로만 구성하는 규칙을 팀과 합의했습니다. HTTP 상태 코드도 5가지 케이스(200·201·400·401·404)를 명확히 정의했고, 에러 응답 형식을 통일했더니 프론트가 예외 처리하기 훨씬 편해졌다는 피드백을 받았습니다.
가장 아쉬웠던 건 페이지네이션 방식을 오프셋 기반으로 먼저 만들었다가, 중간에 커서 기반으로 바꾸면서 프론트 코드를 두 번 고친 일입니다. 처음 설계 단계에서 데이터 증가를 좀 더 고려했으면 좋았을 것 같습니다.