RESTful API에서 중첩 자원을 사용하는 경우

사용자와 링크라는 두 가지 리소스가 있습니다.

사용자는 그들과 관련된 여러 링크를 가질 수 있습니다. 다음 URI에서 사용자와 연결된 링크에 도달 할 수 있도록 RESTful API를 설계했습니다.

/users/:id/links

그러나 항상 링크에 대한 URI가 필요합니다. 때로는 사용자에 관계없이 모든 링크를 원할 수도 있습니다.

이를 위해 나는 가지고있다 :

/links

괜찮습니까? 링크에 대한 두 개의 URI가 있습니까?

대신 다음과 같은 URI를 가진 사용자의 링크에 도달해야하는지 궁금합니다.

/links/user/:id 또는 /links/?user=:id

이렇게하면 링크에 대한 하나의 리소스 만 있습니다.

api rest api-design

— 올리버 조셉 애쉬
소스

흠 .. 이것은 더 /links/user/:id

— 우아해

@ theMarceloR : 세 가지 중에서 특히 명확 하지 않은 유일한 예 입니다. 링크 또는 사용자를위한 리소스입니까? URI는 실제로는 쿼리이기 때문에 중첩 된 리소스 메서드 ( /users/:id/links) 또는 쿼리 문자열 메서드 ( /links/?user=:id)를 사용하면 훨씬 덜 모호 합니다. /links/user/:id일부 프레임 워크에서는보기 좋거나 라우팅하기가 쉽지만 실제로는 매우 혼란 스럽습니다.

— Aaronaught

아니요, 동일한 "사물"(이 경우 링크 목록)에 대해 여러 리소스를 갖는 데 문제가 없습니다.

우리는 최근에 같은 문제로 어려움을 겪고있었습니다. 우리의 결정은 엄격한 소유권이 내포되어 있지 않은 모든 자원을 확보하는 것이 었습니다 . 즉, 링크는

/links -- all links
/links/:linkid -- a particular link

그런 다음 링크 콜렉션의 필터는 조회 매개 변수로 표시됩니다. 따라서 특정 사용자의 링크를 얻으려면 다음을 사용하십시오.

/links?user=/users/:userid

또한 필터를보다 쉽게 구성 할 수 있습니다.

/links?user=/users/10&since=2013-01-01

또한 개념적으로 이해하기 쉽습니다. 항목 모음이 있고 필터를 추가합니다.

즉, 다른 URI 이름 지정 체계보다이 접근 방식에 대한 "RESTful"은 없습니다. 인간이 읽을 수 있고 개발자가 이해하고 수용하기 쉬운 규칙이라는 것입니다. REST는 리소스 식별자에 넣는 내용에 신경 쓰지 않습니다.

— 왁스 윙
소스

"엄격한 소유권이 내포되어 있지 않은 모든 리소스"는 좋은 규칙처럼 들립니다. 무리 감사.

— Oliver Joseph Ash

같은 물리적 개체에 여러 리소스를 사용하는 데 문제 가 있다고 말하지만 실제로는 그렇지 않습니다. 각 개별 링크에는 표준 URL (links / : id)이 있지만 위의 각 리소스는 실제로 필터가 적용된 단일 리소스 (/ links)입니다. 또한 ?user=users/:userid쿼리 문자열에서 이상하게 생각 합니다. 무엇이 잘못 되었나요 ?userid=:userid?

— Aaronaught

@Aaronaught : URI에 충실 이유는 대신에 노출 된 ID의의 고객 만이 사용자에 의해 식별되는 '알고 클라이언트 필요하다, 동등하게 모든 리소스 식별자를 처리 할 수 있도록이다 "/*******"; 곳 *의 불투명하다. 그러나 동일한 식별자를 사용하여 해당 자원을 참조하여 (링크에서와 같이) 해당 자원의 최신 버전을 가져 오는 등의 작업을 수행 할 수 있습니다. 해당 URI의 내용은 원본 서버에서만 이해할 수 있습니다. 즉, 식별자를 변경해야하는 경우 /realm/:businessid/users/:id클라이언트가 전혀 변경되지 않습니다.

— SingleNegationElimination

@TokenMacGuy : 죄송합니다. 귀하의 의견에 대해 전혀 이해가되지 않습니다. 사이의 실질적인 차이가 무엇 /users/:userid/links과 /links?userid=:userid? 두 경우 모두 식별자는 변경되지 않고 해당 리소스의 현재 버전을 가져오고 클라이언트는 동일한 방식으로 처리합니다. 리소스가 아니고 쿼리이기 때문에 표준 URL과 같은 것은 없습니다. 따라서 두 가지 다른 유형의 쿼리 구문입니다. 또한 URL 구조가 변경되면 클라이언트를 어떻게 변경할 필요가 없는지 잘 모르겠습니다. 301이 없으면 REST의 주요 변경으로 간주됩니다.

— Aaronaught 2009 년

@Aaronaught : 귀하의 우려를 오해했을 수도 있습니다. /links쿼리 인터페이스를 지원한다고 가정하면 /links?user=/users/123클라이언트의 리소스 식별자에 대한 블랙 박스 접근 방식이 허용 /links?userid=123됩니다. 후자는 클라이언트가 사용자 ID가 무엇인지, 그리고 그것을 얻는 방법, /users/123또는 에서 얻은 리소스에서 가져 오는 방법을 이해하도록 요구합니다 /links/456/user. 전자는 클라이언트가 수정되지 않은 URI를 사용할 수 있음을 의미합니다. /links/.../user하이퍼 미디어 응답 (예 : Location:헤더)을 제공한다고 가정합니다 .

— SingleNegationElimination

그래서 내 관심사는 / users / : userid / links는 "links"를 반환하지만 user_id가 식별되지 않으면 404를 반환해야합니다.

하나

/ links? userid = : userid는 잠재적으로 비어있는 목록 (실제로 200)을 반환합니다. 그리고 가능합니다.

두 가지 작업 모두 가능하지만 중첩은 나중에 그릴 수있는 추가 기능을 제공합니다.

— 리차드 브라운
소스