일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- RDB
- 자바
- restful
- async
- mariaDB
- REST API
- API
- Spring
- DB 설계
- cmi
- 스프링
- db 스키마
- 미디어서버
- 네이버
- wooza
- JPA
- 이커머스 api
- @async
- Gradle
- 실검
- 라이브커머스
- SpringBoot
- 이커머스
- AWS
- 스트리밍서버
- api설계
- 멀티쓰레드
- 인턴생활
- 서버구축
- autowired
- Today
- Total
Polymor!
[e-commerce] Rest API 설계 디자인 본문
*RESTful API에 대한 기본 이론 설명은 생략하겠습니다.
Rest에 대한 기본적인 이해와 그 규칙들을 좀 체계적으로 공부해보고싶은데 영어 원서에 대한 부담이 없다면 , 책살돈이 없다면(?), 아래 pdf를 제본해서 보길 추천한다. 번역본들은 거의 다 사야되는데.. Mark Masse 저자의 'REST API Design Rulebook' 이 교재는 꽤 유명해서 서치하면 잘 나오는데 책말고 pdf도 있으니 아래 링크에서 확인하면 된다.
github.com/indrabasak/Books/blob/master/REST%20API%20Design%20Rulebook.pdf
개인적인 조언이지만.. Rest에 관한 규칙들은 생각보다 저자들마다 하는말이 좀 달라서 이것 저것 레퍼런스 참고하면 머릿속만 복잡해지지 실무에 딱딱 적용시켜보기가 만만치않다. 꼭!! 책을 통해서 전체 큰 숲을 보고 적용시켜보는 과정을 거치면 좋겠다.
먼저, 이 글을 읽는 당신이 이커머스 REST API를 설계하고자한다면 아래 레퍼런스에서 큰 그림을 먼저 그리며 필요한 요소들이 뭔지 쓱 느낌을 알면 좋을 것같다. 보통 커머셜한 사이트에서 자사 API 지원 도큐멘트들은 차고넘치나 도움이 별로 안되는데! 이건 좀 도움을 많이 봤다.
[ 자 이제 진짜 알겠으니깐 이커머스에 필요한 핵심 API들을 다루어보자 ]
* * 규칙 및 설계 가이드
- CRUD 에 기반한 기본적인 API 먼저 구현하면서 가이드라이닝을 하는것이 효과적이다.
: 막상 해보다보면 Account 같은건 GET 이 많고 , Cart 같은건 PUT이 많다. 그래도 기본 CRUD를 다 구현하는 걸 목표로 잡고하자.
- '수정' 은 가급적 꼭 'PUT' 메소드를 사용할 것. 어떤 이는 'POST'로 작업을 하는데 이는 PUT이 지원안되는 브라우저시절이있었기때문에 통용해서 썼다는데 우리는 경험을 하기위한 것이니 'PUT' 사용하기.
- 국룰이라고 말하는 ' 복수형 명사 ' 사용하기. 예를 들어 회원 삭제를 /account/delete/{id} 이런식으로 동사형은 지양하도록 하겠다.
-
Account
GET | POST | PUT | DELETE | |
회원 추가 | /accounts/ | |||
회원 정보 조회 | /accounts/{id} | |||
회원 정보 수정 | /accounts/{id} | |||
회원 삭제 | /accounts/{id} |
회원 추가 (POST), 즉 회원 가입 의 경우엔 상세 항목들은 RequestBody에 JSON 방식으로 아래와 같이 들어간다.
-
Address
GET | POST | PUT | DELETE | |
배송지 목록 조회 | /accounts/{id}/addresses/{id} | |||
배송지 추가 | /accounts/{aId}/addresses/ | |||
배송지 수정 | /accounts/{id}/addresses/{id} | |||
기본 배송지 설정 | /accounts/{id}/default-address/{id} | |||
배송지 삭제 | /accounts/{id}/addresses/{id} | |||
* 기본 배송지는 어떻게 관리할 것인가?
보통 이커머스를 살펴보면, 배송지는 개인정보랑 따로 관리를 하고, 기본 배송지도 지정할 수 있다. 예를 들어 아래를 보면, 기본 배송지로 어떤 배송지를 택을 하면 페이지 reloading 없이 ajax 로 POST로 패킷이 날라간다. (참고로 마켓컬리는 PUT이 거의 없다.)
나는 default address 를 db 상에서 따로 테이블을 만들어서 관리하고 있고, account-defaultaddress 와 같은 조인테이블을 생성했다.
address 테이블에 default라는 필드를 만들어서 상태를 관리해도 좋을 듯했으나, 여러 고민끝에 조인 테이블을 만들었다.
-
Product
GET | POST | PUT | DELETE | |
상품 조회 | /products?category={id} | |||
상품 추가 (seller) | ||||
상품 수정 (seller) | ||||
상품 삭제 (seller) |
상품은 굉장히 많기 때문에 보통 카테고리로 관리가 된다. 또한 상품은 Seller account type을 가진 회원만이 추가,수정,삭제를 할 수 있다.
그리고 Tag 로 상품을 검색할 때나, '추천순','별점순' 등으로 랭킹을 해야하기 때문에 질의문이 굉장히 많이 쓰이게된다.
이 부분은 다음에 따로 다룰 예정이다.
<진행중>
- Cart
GET | POST | PUT | DELETE | |
- CartItem
- Order
- OrderItem
- Payment
'Web' 카테고리의 다른 글
[AWS] RDB 와 스프링 연동하기 (0) | 2021.02.10 |
---|---|
[e-commerce] JPA 영속성 전이(feat.상품을 장바구니에 담기) (1) | 2021.02.07 |
[e-commerce] ORM & DB 스키마 설계 (1) | 2021.02.06 |
[e-commerce] 개발 동기와 그 여정들 (0) | 2021.02.06 |
wowza 스트리밍 서버 구축하기 (0) | 2020.11.30 |