카테고리 보관물: Software

Software

재귀 리소스에 가장 적합한 RESTful URL 구조는 무엇입니까? 위해 RESTfull 서비스를 만들고 있는데 최고의 URL

트리와 같은 리소스 구조를 위해 RESTfull 서비스를 만들고 있는데 최고의 URL 구조가 무엇인지 궁금하십니까?

세 가지 요구 사항이 있습니다.

  1. 루트 리소스 모음을 얻을 수있다
  2. 개별 자원을 얻을 수있다
  3. 아동 자료 모음을 얻을 수있다

내 현재 생각은 :

/rest/documents
/rest/documents/{id}
/rest/documents/{id}/documents

또한 목록 또는 개별 요소를 나타 내기 위해 단수 / 복수 경로를 사용하려고 생각했지만 단수와 동일한 복수 수의 리소스를 사용한다는 것을 알고 있으므로 이에 대해 결정했습니다.

아무도 위의 생각이 있습니까? 아니면 이것을 구조화하는 다른 / 더 나은 방법이 있습니까?

답변

내 마음에 오는 것은 RESTful API가 URL 자체의 재귀를 반영하지 않도록하십시오. 생각해 보면 당신의 자원은 문서 일뿐입니다.

재귀 구조에 따라 문서를 실제로 저장 한 경우 고유 ID에 대한 맵핑을 작성하고 URL에서 ID를 사용하십시오.

/rest/documents/{id}

이제 다음과 같은 문서가 있다면 :

| DocumentName | DocumentPath | DocumentID |
--------------------------------------------
| ABC | / abc | 1 |
| asd | / abc / asd | 2 |
| asd | / asd | 3 |
| 부 | / abc / asd / boo | 4 |
| 이봐 | / abc / asd / hey | 5 |

요청은이 URL을 참조하여 /abc/asd문서 를 작성합니다.

GET /rest/documents/2

따라서 이제 API 사용자에게 적은 노력으로 구조를 통과 할 수있는 수단을 제공해야합니다. 응답 페이로드 (문서)를 다음과 같은 추가 순회 정보를 포함하는 오브젝트로 랩핑하여 수행 할 수 있습니다.

{
   data: { /* your document goes here */ },
   parent: {"abc": 1 },
   children: [ { "boo": 4 }, { "hey": 5} ]
}

사용자가 단일 레벨에서 너무 많은 문서를 작성하지 않을 것으로 예상되는 경우 하위 목록을 응답에 포함시킬 수 있습니다. 그렇지 않은 경우 사용자에게 하위 문서 ID를 검색하도록 제안 할 수 있습니다 (예 : querystring 매개 변수를 통한 결과 페이징 허용).

GET /rest/documents/2/children?page=2&size=50

마지막으로 querystring 매개 변수를 말하면 querystring 매개 변수를 통해 경로 정보를 직접 제공 할 수도 있습니다.

GET /rest/documents?path=somepath&page=1&size=42

언급 된 모든 접근 방식은 일반 GET /rest/documents문서가 루트 문서 만 반환 할 것으로 예상합니다 .

답변

아마도 이런 것 :

/rest/{rootEntity}/Item/{leafEntity}/{id}
/rest/{entity}/ItemList
/rest/{entity}/ItemList/{leafEntity}

여기서 {rootEntity}는 컬렉션의 시작점이며 {leafEntity}는 트리 내의 명명 된 리프 노드입니다.

위의 매개 변수 중 몇 가지를 추가하여 최신 또는 모두 등을 선택할 수 있습니다.

답변