Зачем кому-то разрабатывать RESTful API с «API» в URI?

Question

Я только что закончил читать Restful Web Services и Никто не понимает REST или HTTP и пытаюсь разработать API с дизайном RESTful.

Я заметилнесколько шаблонов в дизайне API URI:

http://api.example.com/users
http://example.com/api/users
http://example.com/users

Предположим, что эти проекты правильно используют заголовки Accept и Content-type для согласований содержимого между XHTML, JSON или любым другим форматом.

Являются ли эти URI вопросом чистой реализации RESTful против неявного согласования содержимого?

Я считаю, что явное использование API в URIтак что клиент будет ожидать формат данных, который по своей природе не является приятным для человека гипермедиа и может быть более легко использован без явной установки заголовка Accept.Другими словами, API подразумевает, что вы ожидаете JSON или XML, а не XHTML.

Это вопрос логического разделения представлений ресурсов на стороне сервера?

Единственное оправдание, которое я могу придумать, почему кто-то может спроектировать свои URI с поддоменом API, заключается в том, что, исходя из моего предположения, что это метод масштабирования, это должно облегчить загрузку запросов маршрутизации в многоуровневой серверной инфраструктуре.Может быть, существуют ситуации, когда обратные прокси снимают заголовки?Я не знаю.Разные серверы обрабатывают разные представления?

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

Мне не хватает точки?

Мой предложенный проект будет пытаться следовать методикам RESTful, устанавливая соответствующие заголовки, используя соответствующие глаголы HTTP и представляя ресурсы вмода, которую я чувствую, включая «API» в URI, будет излишней.

Зачем кому-то создавать RESTful API с «API» в URI?

Или можетOни?Может быть, моя проблема с непониманием этого дизайна заключается в том, что это не имеет значения , если оно следует некоторой комбинации спецификации, которая может не привести к реализации RESTful API, но близко? Существует несколько способов создания обложки клавиатуры cat. HATEOAS related?

---

Обновление: Во время исследования этой темы у меня естьпришли к выводу, что важно рассматривать идеи REST, а не рассматривать их как религию.Таким образом, наличие или отсутствие «api» в URI является скорее решением проекта, чем постоянным правилом.Если вы планируете публично представить API своего веб-сайта, было бы неплохо использовать поддомен API, чтобы помочь разобраться с логикой приложения.Я надеюсь, что кто-то поделится своим пониманием, чтобы другие учились у него.

Answer 1

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

Answer 2

Это мое понимание и точка зрения на ваш вопрос:

Являются ли эти URI вопросом чистой реализации RESTful по сравнению с неявным согласованием содержимого?

Нет,они не являются частью какой-либо официальной документации (о которой я знаю) и обычно находятся на усмотрение разработчиков стандартов / команд.Например, Zend Framework использует некоторые служебные классы для обнаружения запросов XHR и способов возврата ответов.Конечно, ZF - это не чистый дизайн RESTful (или большинство приложений PHP на самом деле), но все еще возможно писать такие проекты даже на PHP.

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

Это вопрос логического разделения представлений ресурсов на стороне сервера?

Больше или меньше.Например, при выполнении запроса PUT, например, интерфейс не обязательно должен быть полностью обновлен, и часто достаточно простого ответного сообщения.Хотя это ответное сообщение является частью представления, оно не является представлением .Так, например, http://domay.com/users/ вернет интерфейс для управления пользователями (или чем-то еще), http://domain.com/users/api выполнит операции и вернет обновления интерфейса (без перезагрузки страницы).

Я пропустилточка?

Ну, нет.Поскольку это дизайнерское решение использовать или не использовать api в URL, здесь вы ничего не упустите.С правильными заголовками

http://domain.com/users/api/get
http://domain.com/users/get
http://domain.com/users/

могут быть действительными запросами RESTful.

Зачем кому-то разрабатывать RESTful API с «API» в URI?

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

Answer 3

Также имейте в виду, что большинство фреймворков (django, RoR, ...) обеспечивают маршрутизацию на основе URL из коробки. Вероятно, вам нужны разные представления для ответов API и HTML, чтобы по-разному управлять такими вещами, как аутентификация, переход, проверка ограничений и другие конкретные вещи.

Внедрение дополнительной системы маршрутизации на основе HTTP-заголовка, позволяющей, как вы говорите, неявное согласование содержимого, зачастую не стоит усилий.

Answer 4

Видимые пользователю URL-адреса веб-страниц зависят от прихотей веб-мастеров, дизайнеров, корпоративных организаций, маркетинга, моды, технологий и т. Д.

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