RESTful API 변경과정 정리

목표 D-day : 38 일

쿠폰 RESTful API를 1차 작성하면서 느꼈던 것을 정리해보려고 합니다.

ERD

RESTful API 변경 과정

쿠폰 REST API

엔드포인트 URL	메서드	설명
/sellers/{sellerId}/coupons	POST	판매자가 쿠폰을 등록한다.
/buyers/{buyerId}/coupons	POST	등록한 쿠폰을 발행한다.

REST API의 특징은 URI에 리소스 식별자를 사용하고 HTTP 메서드를 곁들여 리소스에 대한 작업을 정의합니다.

덕분에 URI와 HTTP 메서드만 봐도 어떤 작업을 할지 간단하고 명확하게 알 수 있습니다.

리소스라는 것은 결국 테이블과 연결이 됩니다.

회원 테이블에 대한 리소스는 /users가 되고 회원 테이블의 식별자로 개별을 나타날 때는 /users/{userId}와 같은 방식으로 표현합니다.

여기서 쿠폰에 대한 리소스는 어떻게 만들어야할지 고민이 되었습니다.

판매자가 등록하는 쿠폰, 구매자에게 발행하는 쿠폰이 리소스로 표현되어야 하기 때문입니다.

/buyers/{buyerId}/coupons 이렇게 구매자/구매자ID/쿠폰리소스 이렇게 URI를 만드는게 맞는 것인가 생각이 들었습니다.

이렇게 리소스에 발행하는 대상자를 작성하는 경우 유연성이 떨어지고 확장할때도 추가 코드가 필요하게 됩니다.

만약 시스템이 쿠폰을 등록하고, 판매자에게도 쿠폰을 발행할 수 있게 요구사항이 생긴다면

/systems/coupons/,buyers/{buyerId}/coupons/와 같이 같은 기능과 로직도 동일 하지만 URI만 변경됩니다.

그래서 누구나 쿠폰을 만들 수 있고, 누구에게나 쿠폰 발행을 할 수 있도록 유연하게 API를 설계해야한다고 생각했습니다.

/coupons,/issuedCoupons/로 변경하게 되었습니다.

쿠폰 API 변경후

엔드포인트 URL	메서드	설명
/coupons	POST	판매자가 쿠폰을 등록한다.
/issuedCoupons	POST	등록한 쿠폰을 발행한다.

인기, 최근 조회 목록 REST API 변경사항

엔드포인트 URL	메서드	설명
/popular-products	GET	인기 물품 목록 제공
/buyers/{userId}/recent-products	GET	최근 본 물품 목록 제공

인기 상품 목록이나 최근 본 물품 목록은 별도의 테이블에서 관리하지 않습니다.

그러다보니 RESTful API의 URI에 리소스별 식별자를 넣어 별도로 조회할 수 있는 구조가 아닙니다.

만약popular-products인기 물품 목록을 별도로 테이블로 관리하고 식별자로 개별 조회가 가능하다면 이 방식이 맞습니다.

하지만 지금의 인기 물품 목록은 쿼리의 조건에 추가되어 보여주는 목록이기 때문에 정렬에 가깝습니다.

필터링,정렬,페이징 처리와 같은 경우에는 쿼리 스트링을 통해서 표현하는 것이 맞다고 생각됩니다.

그리고 최근 본 물품 목록이 데이터베이스나 캐시에 저장하는 방식이라면 /recent/{userId}와 같이 리소스로 식별할 수 있지만 지금은 클라이언트에서 쿠키나 그외 방법으로 저장했다가 서버에 전달하는 방식이므로 리소스인 products와 쿼리스트링을 추가하는 것으로 변경했습니다.

변경 후

엔드포인트 URL	메서드	설명
/products?order=popular	GET	인기 물품 목록 제공
/products?productIds=123,456,789	GET	최근 본 물품 목록 제공

정리

RESTful API을 다시 작성하면서 해당 리소스가 식별할 수 있는 데이터로 관리되어지는 것이 중요하다는 것을 알았습니다.

그리고 클라이언트에 저장할지, 서버에 저장할지 방식에 따라 API도 변경된다는 것을 알게되었습니다.