Как смоделировать хранилище, которое обеспечивает интеллектуальный доступ на основе REST

Question

Я ищу уникальный способ запроса следующих вариантов использования в режиме REST: -

Предполагается, что хранилище содержит следующее: -

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 Storage, Amazon S3, Mongodb GridFS, репозитории контента Java (JCR 2.0) или простой файловой системе.

Какой был бы идеальный способ хранения и извлечения вышеуказанных данных. Мне бы хотелось, чтобы URL-адрес REST был максимально выразительным, чтобы можно было смоделировать любой из приведенных выше вариантов использования [1-6]. Цените любые указания о том, как спроектировать общий репозиторий, чтобы я мог использовать соответствующие соглашения об именах для извлечения документов на основе вышеуказанных запросов.

Answer 1

Я бы рекомендовал разделить здесь две проблемы: 1) моделирование хранилища данных;и 2) проектирование доступа RESTful.Когда разработка только начинается, эти две проблемы всегда идут рука об руку.По мере развития проекта вам может потребоваться спроектировать совокупные точки или просто разные точки зрения для хранилища.Всегда хорошо понимать, что понятия похожи только на поверхности.

Что касается ваших 7 вопросов, то сначала вам нужно решить, полностью ли заменима концепция «документа» концепцией «экземпляр документа ".Например, если красный шар имеет идентификатор 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-friendly» и «беспокойство» в кавычки, заключается в том, что эксперты по SEO все еще не согласны с тем, предпочитают ли поисковые системы тем или иным способом или вообще не интересуются.

Отс точки зрения реализации, проще, быстрее и масштабируемее использовать параметры URL.Но если вы не ожидаете сумасшедшего количества комбинаций, то оба подхода будут работать одинаково хорошо.

Из личного опыта я бы также рекомендовал группировать ресурсы поискового типа (в отличие от ресурсов идентификации) по общему пути.,Например:

7. /balls/search?color=green

instead of 

7. /balls?color=green

Удачи в дизайне.Нет единственного правильного пути, когда дело доходит до ОТДЫХА.Пока это имеет смысл - ты на правильном пути.