Как структурировать API реального мира в соответствии с принципами REST?

Question

Мы перерабатываем некоторые API и рассматриваем подход REST-стиля, но мы понимаем, что не знаем, как справляться с определенными ситуациями (списки ресурсов с параметрами, которые влияют на выбранные и т. Д.), Или даже как эффективно структурировать URL-адреса для ресурсов, которые могут быть упомянуты сами по себе, но концептуально подчинены какой-либо другой организации (думаю, пользователи/сообщения/комментарии, но с еще более сложными отношениями).

Мы видели много материалов по структурированию API REST для простых случаев, но какой материал доступен, который широко рассказывает об их выборе в более реальных сценариях?

Answer 1

Если вы можете уточнить свои вопросы, здесь будет много людей, которые попытаются помочь.

В противном случае, вот несколько других ресурсов, которые должны быть полезны.

REST Discuss Mailing List

Rest Wiki

REST Cookbook

Лучший совет, который я могу дать вам, хотя, чтобы перестать думать о том, как структурировать URL-адресов и сосредоточиться на том, что ссылки вы собираетесь положить в ваши представления. Как структурировать ваши URL-адреса будет легко, как только вы выясните типы своих медиа.

Answer 2

Во-первых, здесь важно отметить, что REST представляет собой архитектуру , а это означает, что она просто описывает стратегию, которой следует следовать для адресации и работы с ресурсами. Он не говорит, как реализовать эту стратегию, или даже как сказать, если кто-то является RESTful или нет.

Я также думаю, что вы немного смущаете вещи. Вот более точный ответ на ваш два конкретных вопрос:

как эффективно структурировать URLs для ресурсов, которые могут быть отнесены к самому по себе, но концептуально подчинены какому-либо другому лицу (считаешь, что пользователи/сообщения/комментарии, но даже более сложные отношения)

Даже если что-то концептуально подчинено чему-то еще, это не обязательно имеет значение для описания. Например, давайте воспользуемся примером вашего блога. A Blog может иметь много Articles, каждый из которых может иметь один или несколько Pictures. В первой трещины, можно было бы ожидать, чтобы иметь возможность ссылаться на Pictures что-то вроде:

http://api.example.com/articles/123/pictures/456 

Но обратите внимание, что, поскольку Pictures сами по себе являются ресурсы, нет ничего плохого просто делает:

http://api.example.com/pictures/456 

(списки ресурсов с параметрами, которые влияют на то, что выбрано и т. д.)

Это совершенно нормально и чтобы иметь параметры в запросе RESTful. Например, скажем, вы хотите получить первые 500 снимков по дате, начиная с двадцать пятой такой картины.Ваш API может поддерживать что-то вроде этого:

http://api.example.com/pictures?limit=500&offset=25&order=desc&by=date 

Answer 3

Я пойду вперед и предположим, что мы говорим о RESTful HTTP :)

Это, как вы бы выставить «список ресурсов, с параметрами, которые влияют на что выбрано ":

/список {поиск части}

Где найти часть некоторой произвольной строка, которая используется для целевой„раздела“ресурс списка?.

Обычный способ сделать это (так что браузеры + HTML формы работы), чтобы иметь пар ключ/значение для каждого параметра т:

/список name1 = Фреда & Имя2 = DAVE & name3 = матовые

Данное соглашение об организации вашей части поиска не является обязательным, но вы обнаружите, что в соответствии с этим шаблоном упрощается создание HTML-кода для вашего приложения. Это не было бы менее достоверно через HTTP и URI использовать следующее:

/список Фред, Дэйв, матовый

как эффективно структурировать URLs для ресурсов, которые могут быть отнесены к по ? себя, но концептуально подчинены каким-либо другим лицом

в ОСТАЛЬНЫХ нет такого понятия, как «структурированные» URI. URI - это просто уникальный идентификатор - сходства и шаблоны в структуре URI могут упростить организацию серверной логики и сделать ее «красивой» для пользователей, чтобы посмотреть и выяснить, но если вы выполняете REST, нет никакой связи между следующими :

/Foo

/Foo/бар

.. если вы не создать отношения с гиперссылкой от одного к другому. Это правило обычно называется «гипертекстовым ограничением» или «HATEOAS».

Сказав это - нет ничего плохого в том, чтобы «приукрашивать» ваши URI. Просто имейте в виду, что (если вы хотите «сделать REST»), вы должны объединить все вместе. Большинство API, разоблачить «вложенные ресурсы», как это:

/страны/Англия/город/Лондон

Надежда, что полезно :-)