Restful은 봐도 봐도 모르겠네요..

Question

자료를 찾아봐도 계속 어떤 상황에선 어떻게 하는지 상상만으로 하니 답답하네요.명확한 답 알려줄 선배님이 따로 없어서 여기 선배님들께 여쭤봅니다.https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design위 글 말고도 다른글들도 많이 찾아봤는데, 결론은 상태 업데이트시엔 PUT 쓰고, 동사 쓰지 말라는 겁니다.만약 product 의 입고, 출고를 하면 둘 다 상태 업데이트라서 url이 PUT "/product/{id}" 가 되는데...payload에 입고인지 출고인지 구분값을 받아 메소드내부에서 로직을 구분해야 할까요? 아니면 product의 출고는 "order/{id}" 이런식으로 처리하는게 맞는걸까요restful은 봐도 봐도 헷갈리네요

동도인 · Answer

저라면 입고 인지 출고 인지 status 값을 받아서 처리할거 같습니다.설계에 따라 다르겠지만 처음 로직은 거의 비슷(제품 존재여부 , 제품상태 여부 등등) 비슷할거 같고 출고 인지 입고인지에 따라로직 이 변경될거 같아서 중복 로직을 제거하기 위함도 있습니다.

공지사항 · Answer

param이나 requestBody에 enum값으로 구분값을 받으면 되죠

chytonpide · Answer

모델의 계층구조를 URL에 나타내지 않아도 좋습니다.header에 별도의 오퍼레이션(동사)를 지정하지 않는 이상, 원래 PUT 만가지고는 복잡한 행동을 표현하기 쉽지 않습니다. PATCH 사용도 고려해 보세요. 백엔드의 오퍼레이션의 실행(완전히 동사)은 op 페이로드를, 상태변경은 전용페이로드를 쓰는 식입니다.PATCH /products/{productId} { "op":"rebalance" // 단순한 상태변경과 구별되는 다른 오퍼레이션들 "value":null // 필요한 경우 설정 } PATCH /products/{productId}/content { "name": "productName" "price":10000 }

RWB · Answer

PUT과 PATCH에 대한 구분을 이해하시면 좀 더 원활한 구성이 가능할거구요굳이 상품이라고 해서 상품의 입/출고 전체를 /product 엔드포인트 하나에 묶는건 별로 좋지 않은 생각입니다.저라면 차라리 /product/in/{id} /product/out/{id} 를 하겠어요.입출고라는 서로 다른 역할을 하나의 메서드에 묶는 것도 SPR에 좋지 않습니다.물론 권장하지 않는다고는 하지만, 어디까지나 비권장사양일뿐, 실제로 실무에선 엔드포인트를 저런 수준으로까지 구분해서 관리하지 않습니다.만약 그것도 RESTful을 위반하는게 아니냐 물으신다면... 현재 RESTful API로 구성했다고 주장하는 대부분의 API들은 HATEOAS를 무시하고 있어 RESTful 규칙에 위배됩니다.처음 들어보시죠? 다들 그래요우리도 교통법규 지키면서 운전한다고 생각해도, 알고보니 위반이고, 알고보니 위반이 아니였고 하는 것들이 많습니다.그냥 RESTful 같은 규칙에 너무 얽매이진 말라는 말씀을 드리고 싶습니다.(그렇다고 RESTful 아예 무시하란 말씀은 아닙니다.)

rani go · Answer

다들 답변 감사합니다. 추가로 restful 의 설계 목적이 URL과 메소드만 보고도 직관적으로 해당 API가 어떤 자원에 대해 무슨 작업을 수행하는지 알기 위함이었다는게 생각났는데요, payload(requestBody)에 인자값으로 받아서 동작이 변경된다면 restful 의 목적과 어긋난다는 생각이 드네요ㅠㅠ

kenu,전독시 · Answer

간단하게 생각했는데 좋은 질문입니다.저는 CRUD RESTful을 이렇게 생각했습니다.정보 가져오기 GET정보 저장하기 POST정보 수정하기 PUT정보 삭제하기 DELETE이런 경우 말고 다른 게 있다니 도전적이네요.

퓨리오사 · Answer

/product/{id} PUT 만으로 모든 행위를 다 커버하기는 한계가 있어보입니다.입/출고는 상품 정보를 단순 업데이트하는게 아니라 입/출고라는 비즈니스 관점에서 보면 분리해서 아래와 같이 API를 추가로 두는 방법이 더 나을 것 같습니다./products/{id}/shipments /products/{id}/receipts

scissors hand · Answer

저 같으면입고서, 출고서도 서류로 존재 -> Inbounds, Outbounds 리소스로 관리 (여러 종의 상품들이 한 입고 동작에 들어올 수 있음)재고도 여러 상품들에 대해 현재 재고를 한꺼번에 확인 필요 -> stocks 리소스로 관리입고(Inbound)GET /inbounds → 모든 입고 기록 조회GET /inbounds/{inboundId} → 특정 입고 기록 조회POST /inbounds → 새로운 입고 처리{ "warehouse": "A", "items": [ { "productId": 1, "quantity": 20 }, { "productId": 2, "quantity": 10 } ], "orderId": 123, "shippedBy": "user456", "date": "2025-11-10" }출고(Outbound)GET /outbounds → 모든 출고 기록 조회GET /outbounds/{outboundId} → 특정 출고 기록 조회POST /outbounds → 새로운 출고 처리{ "warehouse": "A", "items": [ { "productId": 1, "quantity": 20 }, { "productId": 2, "quantity": 10 } ], "orderId": 123, "shippedBy": "user456", "date": "2025-11-10" }상품(Product)GET /products → 상품 목록GET /products/{productId} → 상품 상세POST /products → 상품 생성재고(Stock)GET /stocks → 모든 상품의 재고 현황GET /stocks/{productId} → 특정 상품 재고 현황

Restful은 봐도 봐도 모르겠네요..

8개의 답변

Q&A 목록