| 제목 | RESTful API 만들때... 정답은 없겠지만 궁금한게 있습니다 | ||
|---|---|---|---|
| 카테고리 | 기타 | ||
| 글쓴이 | 마PD | 작성시각 | 2019/11/23 21:54:42 |
|
|
|||
|
안녕하세요 RESTful API 를 만들고 있는데요..
뭔가 정답은 없는듯 한데 어느 방향이 더 나은 방법일지 싶은게 있습니다... 음... 일종의 사용 내역을 뿌려주는 API 인데요. 쇼핑몰 구매이력이라고 보시면 될듯 하네요
DB 테이블은, 구매 이력 테이블이 따로 있고, 해당 구매 이력에 소속된 상품 정보가 들어 있는 테이블이 있습니다. 클라이언트 화면에는 구매이력과 해당 구매에서 구입한 상품 정보를 리스트로 보여주고자 합니다.
구매이력 -- 1 - 카드결제 : 상품 AA 구매 2 - 카드결제 : 상품 BB 구매 3 - 카드결제 : 상품 CC 구매 4 - 가상계좌 : 상품 B 구매 5 - 무통장입금 : 상품 A 구매
이때 api 설계를 어떻게 해야할지 싶습니다. 구매 이력을 몽땅 데이터를 만들어서 하나의 api 호출만으로 해당 리스트를 불러올 수 있게 해야할지 구매 이력 (숫자와 결제방법)만 내려주는 api 만들고 해당 구매번호로 다시 상세 내역을 불러오는 api를 각각 만들어야할지.
한꺼번에 만들경우 api 의 재활용이 떨어지는 거 같고 자칫 쿼리가 무거워지는 느낌도 있습니다. (join... 물론 인덱스를 태우긴 하지만요) 각각 만들경우 비교적 가벼워지는거 같기는 하지만 api 호출이 많이 일어나게 됩니다.
현재는 한꺼번에 불러오게 만들고 있습니다만, 뭔가 이 덩어리를 쪼개놔야하는거 아닌가 하는 찝찝한 기분이 드네요 -_-;;;; API 를 만들때 어느 방향성을 가지고 만드는게 좋을까요? |
|||
| 다음글 | SSL(https) 적용 관련해서, 제가 생각하는게 맞... (2) | ||
| 이전글 | AJAX를 통해서 결과를 받은 후에 다른 페이지에서 동... (5) | ||
|
엽토군
/
2019/11/24 01:34:10 /
추천
0
|
|
변종원(웅파)
/
2019/11/24 22:52:39 /
추천
0
api가 바뀌면 프론트단이 바뀌게 되겠죠. 이미 개발되어 사용되고 있는 상황이면 1. 출력요구에 따라 api를 개발하고 (이미 진행) 2. 쿼리 병목이 생기는 부분을 튜닝하고 3. join 분리(원쿼리 방식에서 쿼리를 분리하고 서버 파워로 데이터를 재생산하는 형태) 해서 처리해보고 4. 그래도 현상 해결이 안되면 출력형태를 변경하는 식으로 처리하는게 좋습니다. 완벽하게 발란스가 맞도록 개발을 할 시간도 없을 뿐더러 예측하지 못한 상황은 생기게 마련입니다. 상황에 따라 서브쿼리, 조인 등을 없애고 쿼리를 분리하여 sql 부하를 줄이고 그 부하를 서버단(php) 파워로 분산하는 것도 방법입니다. 그전에 불필요한 데이터량을 제한할 필요도 있고 어떤 것이 불합리한지 부터 파악해서 하나하나 제거해 나가야 합니다. |
|
마PD
/
2019/11/26 15:53:10 /
추천
0
기존 서비스가 있긴 하지만 너무 오래 되었고 코드가 저질이라(...) 아예 새롭게 만들고 있는데, 어떤 방향성을 가지고 해야할지 고민 되어서요. 새롭게 만드는건 아직 라이브 단계가 아니라 뜯어고칠수는 있으나 마감일이 얼마 남지 않았습니다 ㅋㅋ
음... 결국 부하가 어디서 걸리느냐에 따라, 쿼리로 해결하는 방법도 있지만 굳이 어려운건 서버로 가져와서 PHP 서버가 처리하게끔 하는 방법을 '적절히 잘' 선택해야 겠네요... 라이브 서비스를 개선하는게 아니라 아예 새롭게 만드는 거다보니, API에 기능을 다 합쳐놔야할지. 기능별로 쪼갠 뒤 API 에서 기능들을 호출해서 조합하는게 맞을지 고민됐었습니다. 무거운 쿼리 하나를 던지느냐, 가벼운 쿼리 여러개를 던지고 PHP에서 재단하느냐 였는데... 큰 문제가 없다면 묶고 아니라면 쪼개서 부하를 나누는 방향으로 해야겠네요. 감사합니다! |
|
변종원(웅파)
/
2019/11/26 16:43:10 /
추천
0
마PD/ 그것도 api 성격에 따라 정하기 나름입니다. 조금 오래 걸려도 기다릴 수 있다(운영어드민용 api이고 사용자 별로 없고 조금 느려도 된다)면 한방 쿼리로 만들어도 됩니다. 즉각적인 리턴이 필요하다면 튜닝과 분산을 통해 빠르게 처리할 수 있도록 구성을 해주시면 됩니다.
|
저같으면 구매이력들 자체를 하나의 리소스로 간주하고 다음과 같이 하겠습니다.
GET /transaction/?method=creditcard,wiretransfer&productId=9987 [ { "id": 88736, "txId": "A23tj0000Xkdfng1r", "created_at": "2019-11-13 09:01:02", "netPayment": 41500.0, "options": { "color": "Navy", "size": "S", }, "method": { "id": 1, "name": "creditcard" }, "product": { "id": 9987, "name": "옷", "priceKRW": 44900.0 }, "user": { "id": 23287, "email": "foo@bar.com", } }, { // ... } ]한마디로 index API에 쿼리를 거는 방식인데요.
쿼리에 해당되는 모든 구매내역을 가져오되, 각 구매내역의 결제유형, 구매상품 등은 그 구매내역의 속성으로서 추가해 한꺼번에 가져옵니다. 어차피 테이블끼리 단순 일대다로 관계 걸려 있을 테니 JOIN 걸어서 가져오는 게 아주 어렵지는 않을거잖아요. 그러니 그냥 바로 다 불러서 배열에 꽂습니다. 프론트에서는 쓰고 싶은 자료만 transactions.0.product.name 하는 식으로 가져와 쓰면 되구요.
이걸 한꺼번에 가져오지 않고 따로따로 그때그때 불러오는 건 선택의 문제 같은데.. 자료가 너무 방대하면 비동기식으로 처리할 필요가 있을테니 그때는 확실히 이런 식으로 응답하도록 처리하면 대충 되겠지요.
[ { "id": 88736, // 중략 "methodId": 1, "productId": 9987, "userId": 23287 } ]애초에 상품, 결제수단 등에 대한 각각의 REST API가 아예 없다면 만들어놓는 차원에서 별도로 만들어두어도 될 것 같구요. 어떤 식으로 아키텍처를 잡을것이냐의 문제일 것 같긴 하네요. 제 생각은 그러한데 참고가 될는지 모르겠네요.