#api #http #rest #uri
#API #http #rest #uri
Вопрос:
Похоже, есть два способа, которыми я могу создать свой REST API. Я могу создать пользователей с помощью POST без указания URI, и это создаст пользователя и вернет URI, или я могу создать пользователей с помощью PUT и самих указать URI.
Когда следует использовать один вместо другого? Ключевое отличие здесь в том, что в одном методе МОЯ система решает, каким должен быть уникальный идентификатор и, следовательно, URI для ресурса, в другой ситуации ОНИ указывают, каким он должен быть, когда я создаю.
Ответ №1:
В основном это сводится к тому, готовы ли вы уступить контроль над присвоением имен ресурсов клиенту.
Самая большая проблема заключается в том, чтобы просто иметь дело с конфликтами (если я ДОБАВЛЮ /photo.png, а вы ДОБАВИТЕ / photo.png , это нормально?).
Ответьте на эти вопросы, и вы на своем пути.
Комментарии:
1. Неверно. То, что клиент сам создает URI, нарушает один из принципов стиля RESTful.
2. Да, нет. «Орган по присвоению имен, который назначил идентификатор ресурса, позволяющий ссылаться на ресурс, отвечает за поддержание семантической достоверности сопоставления с течением времени». Ничто не говорит о том, что клиент не может быть этим органом по присвоению имен и отвечать за обслуживание пространства имен и за то, что ресурс означает в этом пространстве имен. Кроме того, «… Вместо этого REST полагается на то, что автор выбирает идентификатор ресурса, который наилучшим образом соответствует природе идентифицируемой концепции «. Этим «автором» может быть система или клиент, как определено приложением и его семантикой.
3. @tomc Клиенту разрешено создавать правила на основе URI, определенные в типе носителя. Филдинг говорит об этом в этой статье roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven «разрешить серверам инструктировать клиентов о том, как создавать соответствующие URI»
Ответ №2:
Когда ваш пользователь указывает идентификатор ресурса, он может ввести его в URI; идентификатор, к которому он выполняет ВВОД, является спецификацией идентификатора ресурса.
Когда вы указываете идентификатор ресурса, они могут отправлять сообщения в URI родительского элемента / группы; ваша система присвоит URI ресурсу и вернет его клиенту, чтобы он мог ссылаться на созданный им ресурс.
Ответ №3:
Ответ на этот вопрос зависит от двух более конкретных вопросов:
- Знают ли клиенты местоположение создаваемого ресурса? (Это может иметь место, если, например, доступ к пользователям осуществляется через имя пользователя, а не через идентификатор, назначенный сервером.)
- Есть ли у клиентов полное представление создаваемого ресурса? (Это может быть не так, если некоторая часть вашего ресурса вычисляется сервером.)
Если ответ на оба этих вопроса «да», то, вероятно, уместно указать PUT. Если вы ответили «нет» на любой из них, тогда вам следует придерживаться POST.
Комментарии:
1. Вы все еще можете поместить представление и заставить сервер вычислять его части.
2. @Darrel Miller: это, безусловно, правда, что вы можете! Тем не менее, я бы интерпретировал спецификацию HTTP как указание, которое должно выполняться с полным ресурсом, а не с частичным ресурсом, который модифицируется за кулисами. (Например. «запрашивает сохранение вложенного объекта» или «идентифицирует объект, вложенный в запрос».)
3. Но в HTTP ничего не говорится о представлении ресурса, так что, безусловно, решение о том, каковы именно соответствующие представления, а также определения «полного» и «частичного», остается за приложением.
4. Объяснение PUT было значительно расширено в Httpbis, чтобы попытаться прояснить эту проблему и другие. tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#page-18
Ответ №4:
Я могу создать пользователей с помощью POST без указания URI, и он создаст пользователя и вернет URI, или я могу создать пользователей с помощью PUT и указать URI самостоятельно.
Когда следует использовать один вместо другого?
Используйте первый.
В RESTful HTTP клиент никогда не должен создавать URI. Служба должна быть хорошо подключена, что означает, что клиент должен только следовать URI, предоставляемым сервером, и отправлять запросы к этим URI.
Это создает лучшее разделение между клиентом и сервером и упрощает внесение изменений в службу, не нарушая работу существующих клиентов.
(И да, множество существующих API ошибаются в этом)
Здесь есть действительно хороший пост Филдинга, связанный с этой темой:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Комментарии:
1. Шаблоны URI могут поддерживать управление гипертекстом API, все еще позволяя клиентам настраивать запросы.
2. По моему личному мнению, POST / redirect — это такая простая и стандартизированная идиома, что я бы сказал, что это должно быть по умолчанию, если у вас нет веских причин выбирать иначе. Хотя это, конечно, не канон.
3. Шаблоны URI — это не единственный способ, которым сервер может инструктировать клиентов о том, как создавать URI, но они определенно являются одним из лучших способов. Главное — убедиться, что спецификация типа носителя или отношения ссылки документирует механизм настройки.