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

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

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

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?

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

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

Ответ 1

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

Являются ли эти 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. Таким образом, при просмотре запроса в журналах, документации и т.д. Это будет понятно.

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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