내 API에 편안한 디자인에 대해 혼란 스럽습니다.
최종 사용자와 백엔드 (관리자)의 두 가지 역할이 있습니다. 백엔드 역할을 사용하면 사용자의 모든 리소스에 액세스 할 수 있습니다.
사용자는 많은 주문을 가질 수 있습니다.
그래서 사용자 리소스에 기반을 정의했습니다.
GET /users/{userID} -- get User Information
GET /users/{userID}/orders -- list user order list
POST /users/{userID}/orders -- user make an order
하지만 어 .. 일부 온라인 문서를 참조한 후 인증 단계 이후에 암시 적 사용자 ID가 식별되므로 다음은 주문 리소스 를 사용하여 다른 디자인입니다 .
GET /orders/ --list user order list by user account(backend can get all)
GET /orders/{orderID} --get orderID by userID
POST /orders/ -- user make an order.
백엔드 사용자가 사용자별로 주문을 나열하려는 경우이 정의를 사용합니다. 어떤 방법을 사용해야합니까?
GET /orders?user={userID} (user as query parameter) -- List order with userID
또는
GET /users/{userID}/orders
Pls는 어떤 디자인 ( 사용자 또는 주문 리소스)이 더 나은지 조언 하고 그 이유는 무엇입니까? Tks,
더 나은 디자인은 사용 사례에 따라 다릅니다.
예를 들어 두 명의 사용자가 있다고 가정합니다.
userID=1)userID=2)또한 Alice가 이미 인증되어 백엔드가 userID=1어딘가에서 사용 가능 하다고 가정 해 봅시다 .
Alice가 자신의 주문을 나열하려는 경우 가장 짧은 방법은
GET /orders
그리고 백엔드 사용자에게 userID.
요청이 인증 된 사용자의 주문을 검색한다고 가정 해 보겠습니다. Alice가 시도하면 어떻게 /users/2/orders됩니까? Bob의 명령을 볼 수 있습니까? Alice가 많이 잘못 입력하고 쿼리를 발행하면 /users/2/어떻게됩니까?
userID미래에서 주문에서 제거 (> 주문 - -> 장바구니의 사용자와 같은 미래의 새로운 관계가있다 가정 해 봅시다)? 업데이트하기 쉬운 URI 체계는 무엇입니까?따라서 간단한 대답은 없으며 사용 사례에 따라 다릅니다. 주문 만 검색하는 경우 {GET|POST} /orders유연성과 단순성을 최대한 활용하는 것이 좋습니다 .
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다