[TIL] 9/30 ERD 테이블, API 설계 및 수정

이전 내용

 

[TIL] 9/27 API 설계 명세서 작성하기

 

 

1. ERD 테이블 그리면서 API 명세서 수정하기

 

아직 관계까지 표시하지 않았지만 ERD 테이블을 그렸다. 이제 참고해서 API 수정을 해보도록 하자. 

 

1.1. 좋아요 API 수정

 

기존에는 book 에 있는 likes 필드를 수정해주는 것으로 설계했지만, likes 테이블을 따로 만들어 놓고 좋아요 누르기 또는 취소할 때마다 행을 추가/삭제해주는 것으로 수정.

• 좋아요를 누를 때마다 likes 테이블에 행을 추가
• 좋아요를 취소할 때마다 likes 테이블에 행을 삭제 

Method	PUT -> POST
URI	/likes/{bookId}
HTTP status code	성공 200
Request body
Response Body

 

Method	PUT -> DELETE
URI	/likes/{bookId}
HTTP status code	성공 200
Request Body
Response Body

 

 

1.2. 장바구니 API 수정 & 주문 예상 API 수정(사실 장바구니의 연장선상임)

 

장바구니 페이지를 생각해보면 각 아이템들을 선택해서 주문할 수 있도록 되어있는데, 짜뒀던 장바구니 API 에는 아이템 별 id 가 없다. primary key 역할을 할 필드가 없는 것이기 때문에 cartItemId 라는 필드를 추가해주었다. 

Method	POST
URI	/cart
HTTP status code	성공 201
Request Body	{       cartItemId: "아이템 id",     bookId: "도서 id",     count: 수량      }
Response Body

 

 

주문 예상 상품 목록은 아직 주문이 안된 목록들이다.

즉, 장바구니 페이지에서 선택 당한 애들만 모아서 화면에 보여주기만 한 것이기 때문에 주문 API 가 아니라 주문 "예상" API 로 이름을 수정하였다. 

 

그래서 직전 페이지인 장바구니 페이지에서 선택 당한 아이템이 무엇인지 request body 에 cartItemId 를 담아서 보낸 것을 받아 해당 item 의 정보를 가져오면 된다. 

 

Method	GET
URI	/cart
HTTP status code	성공 200
Request Body	[ cartItemId, cartItemId, ...]
Response Body	[      {         cartItemId: "장바구니 도서 id",          bookId: "도서 id",          title: "도서 제목",          summary: "도서 요약",          count: 수량,          price: 가격      },     {          cartItemId: "장바구니 도서 id",          bookId: "도서 id",          title: "도서 제목",          summary: "도서 요약",          count: 수량,          price: 가격      },      ... ]

 

 

 

2. API 설계 - 결제(주문) API 

 

2.1. 결제하기 = 주문하기 = 주문 등록 = 데이터베이스에 주문을 INSERT 하겠다 = 장바구니에서 주문된 상품은 DELETE 하겠다

 

request body 에 담겨있는 값들을 받아서 데이터베이스에 저장하면 된다. 

 

여기서 중요한건 request body 에 items 를 배열로 받을 때 bookId 를 받는다는 것이다. 

장바구니에서 결제하기를 눌렀을 때 결제창으로 이동하게 되므로, cartItemId 를 받을 것이라고 생각할 수 있지만, 장바구니에 담겨있는 아이템들은 결제하기를 누르면 사라져버리기 때문에 bookId 로 해야한다. 추가로 주문 수량은 아이템 별로 다를 수 있기 때문에 bookId 와 count 값까지 같이 담아와야 한다. 주문하고 장바구니에 주문된 항목들을 삭제해줘야 하기 때문에 cartItemId 를 알고 있어야하기 때문에 cartItemId 값도 같이 담아야 한다. 

Method	POST
URI	/orders
HTTP status code	성공 200
Request body	{     items: [{         cartItemId: 카드 아이템 id,         bookId: 도서 id,          count: 수량     },     {         cartItemId: 카드 아이템 id,         bookId: 도서 id,          count: 수     },     ...     ],     delivery: {         address: "주소",         receiver: "이름",         contact: "010-0000-0000"     },     totalPrice: 총 금액 }
Response Body

 

 

2.2. 주문 목록 조회

Method	GET
URI	/orders
HTTP status code	성공 200
Request body
Response Body	[     {            order_id: 주문 id         created_at: "주문일자",         delivery: {             address: "주소",             receiver: "수령인",             contact: "전화번호"         },         bookTitle: "대표 책 제목",         totalPrice: 결제 금액,         totalCount: 총 수량     } ]

 

대표 책 id 와 totalCount 의 경우 타고 가서 긁어와야 하는데, 그럴바에 order 테이블에 데이터를 넣을 때 대표 책 id 를 따로 넣어두는 것이 더 효율적일 것 같기 때문에 order 테이블에 book_title 필드를 추가

 

2.3. 주문 상세 상품 조회 

 

특정 주문 id 에 해당되는 상품들의 정보를 돌려줌 -> order 테이블 조회가 아니라 orderBook 테이블을 조회하는 것

orderBook 테이블을 books 테이블과 조인해서 필요한 정보들을 조회할 수 있도록 해주면 된다. 

Method	GET
URI	/orders/{orderId}
HTTP status code	성공 200
Request body
Response Body	[     {         bookId: 도서 id,         bookTitle: "도서 제목",         author: "도서 작가",         price: 가격,         count: 수량     },     {         bookId: 도서 id,         bookTitle: "도서 제목",         author: "도서 작가",         price: 가격,         count: 수량     },     ... ]

 

 

 

느낀 점

 

처음 API 를 설계하고나서 ERD 테이블을 그려보니 수정해야할 점이 보였고, API 하나를 수정하다보니 다른 API 수정이 필요해지고 계속 수정할 부분이 생겼다. API 설계는 계속해서 수정한다고 하는데, 왜 그런지 알 것 같았다. 

 

API 수정하면서 생각하기 어려운 부분도 많았어서, 스스로 많이 설계해보고 페이지에 필요한 정보가 무엇인지 다음 화면으로 넘어갈 때 넘겨줘야할 정보가 무엇인지 계속 생각해보는 것이 필요할 것 같다는 생각이 들었다.