내가 REST 방식으로 다음과 같은 사용 사례를 조회 할 수있는 독특한 방법을 찾고 있어요 지능형 REST 기반 액세스

Question

을 제공하는 스토리지 저장소를 모델링하는 방법 : -

저장소를 가정

에는 다음이 포함됩니다 : -

a. green color ball image of 1cm radius 
b. yellow color ball image of 1cm radius 
c. blue color ball image of 1cm radius 
d. green color ball image of 2cm radius 
e. yellow color ball image of 2cm radius 
f. blue color ball image of 2cm radius 
g. computer monitor icon image of size 32x32 pixels in png format 
h. computer monitor icon image of size 64x64 pixels in png format 
i. computer monitor icon image of size 32x32 pixels in ico format 
j. computer monitor icon image of size 64x64 pixels in ico format 
k. HR travel policy 
l. HR new hire policy 
g. HR promotion policy 

1. Find all documents published after a certain date? 
2. Find all documents published before a certain date? 
3. Find all documents published between a certain set of dates? 
4. Find all balls which are 1cm in radius 
5. Find all documents whose download format is "png" 
6. Find all documents whose size is 32x32 pixels 
7. Find all balls which are green in color. 

스토리지 저장소는 Google 스토리지, Amazon S3, Mongodb GridFS, Java 콘텐츠 저장소 (JCR 2.0) 또는 간단한 파일 시스템을 기반으로 할 수 있습니다.

위의 데이터를 저장하고 검색하는 가장 이상적인 방법은 무엇입니까? 위의 사용 사례 중 하나를 모델링 할 수 있도록 REST URL을 최대한 표현하기를 원합니다 [1-6]. 위의 쿼리를 기반으로 문서를 가져 오는 데 적절한 명명 규칙을 사용할 수 있도록 일반 리포지토리를 디자인하는 방법에 대한 모든 정보를 제공하십시오.

Answer 1

2 가지 문제를 여기에서 구분하는 것이 좋습니다. 1) 저장 저장소 모델링. 2) RESTful 액세스 설계 개발이 시작될 때,이 두 가지 관심사는 언제나 함께합니다. 프로젝트가 진화함에 따라 저장소에 대한 집계 지점 또는 단순히 다른 관점을 설계해야 할 수도 있습니다. 개념이 서페이스에서만 유사하다는 것을 이해하는 것이 항상 좋습니다.

7 가지 질문이있는 한 먼저 "문서"개념을 "문서 인스턴스"개념으로 완전히 대체 할 수 있는지 결정해야합니다. 예를 들어 빨간 공이 ID가 1이면 다음 두 자원이 유효합니까?

/documents/1 
/balls/1 

새로운 공을 다음 자원 모두에 게시 할 수 있습니까 아니면 하나만 추가 할 수 있습니까?

/documents/ 
/balls/ 

하나 이상의 리소스로 모든 녹색 공을 찾을 수 있습니까?

/documents/type/ball/by/color/green 
/balls/by/color/green 

API에 분명한 답을하는 것이 중요합니다.

두 번째로, "SEO 친화적 인"방법으로 리소스를 보길 원합니다. 예 :

1. /documents/after-date/2001-01-01/ 
2. /documents/before-date/2010-12-31/ 
3. /documents/after-date/2001-01-01/before-date/2010-12-31/ 
7. /balls/by/color/green 

or 

1. /documents?after-date=2001-01-01 
2. /documents?before-date=2010-12-31 
3. /documents?after-date=2001-01-01&before-date=2010-12-31 
7. /balls?color=green 

API가 활짝 열려 있고 공개 웹 사이트에서 링크를 사용하는 경우 이는 "우려"입니다. 내가 "SEO 친화적 인"그리고 "우려"를 따옴표에 넣는 이유는 SEO 전문가들이 검색 엔진이 어떤 방식 으로든 또는 엔진이 전혀 신경 쓰지 않는다면 여전히 동의하지 않기 때문입니다.

구현의 관점에서 URL 매개 변수를 사용하는 것이 더 쉽고 빠르며 확장 성이 뛰어납니다. 그러나 당신이 미친 양의 조합을 기대하지 않는다면 두 접근법 모두 똑같이 잘 작동 할 것입니다.

개인적인 경험에서 공통 경로로 검색 유형 리소스 (ID 리소스에 반대)를 그룹화하는 것이 좋습니다. 예 :

7. /balls/search?color=green 

instead of 

7. /balls?color=green 

디자인을 가진 행운을 빕니다. REST는 올바른 방법이 없습니다. 그것이 의미가있는 한 - 당신은 좋은 길을 가고 있습니다.