Можно ли объяснить веб-понятие УСПОКОИТЕЛЬНЫХ?
Никакие браузеры не обрабатывают 301 и 302 ответов правильно. И на самом деле стандарт даже говорит, что они должны обрабатывать их «прозрачно», что является МАССИВНОЙ головной болью для поставщиков библиотеки Ajax. В Ra-Ajax мы были вынуждены использовать HTTP-код ответа HTTP 278 (только некоторый «неиспользуемый» код успеха) для обработки прозрачных переадресаций с сервера ...
Это действительно раздражает я, и если у кого-то здесь есть «pull» в W3C, я был бы признателен, что вы могли бы сообщить W3C знать , что нам действительно нужно обрабатывать 301 и 302 коды ...! ;)
7 ответов
УСПОКОИТЕЛЬНОЕ приложение является приложением, которое выставляет его состояние и функциональность как ряд ресурсов, которыми клиенты могут управлять и приспосабливают определенному набору принципов:
- Все ресурсы исключительно адресуемы, обычно через URIs; другое обращение может также использоваться, все же.
- Всеми ресурсами можно управлять через ограниченный набор известных действий, обычно CRUD (создайте, считайте, обновите, удалите), представленный чаще всего через POST HTTP, ПОЛУЧИТЕ, ПОМЕСТИТЕ и УДАЛИТЕ; это может быть другой набор или подмножество, хотя - например, некоторый предел реализаций, которые устанавливают, чтобы считать и изменить только (ПОЛУЧАЮТ и ПОМЕЩАЮТ), например
- данные для всех ресурсов переданы через любое ограниченное количество известных представлений, обычно HTML, XML или JSON;
- коммуникация между клиентом и приложением выполняется по протоколу без сохранения информации о состоянии, который допускает несколько многоуровневых посредников, которые могут перенаправить и кэшировать запросы и ответные пакеты прозрачно для клиента и приложения.
статья Wikipedia, на которую указывает Tim Scott, предоставляет больше подробную информацию об источнике REST, подробных принципов, примеры и так далее.
Лучшее объяснение, которое я нашел, находится в этом учебное руководство .
RESTВсего несколько точек:
- УСПОКОИТЕЛЬНЫЙ не зависит от платформы, которую Вы используете. Это зависит от архитектурного стиля, который это описывает. Если Вы не следуете за ограничениями, Вы не являетесь УСПОКОИТЕЛЬНЫМИ. Ограничения определяются на половине страницы Главы 5 документа Roy Fielding, я поощряю Вас идти и читать его.
- идентификатор непрозрачен, и не делает сборник решений канцлерского суда никакая информация вне идентификации ресурса. Это - nmae, не входные данные, просто имена. что касается клиента, это не имеет никакой логики или значение вне знания, как создать querystrings из тега form. Если Ваш клиент создает его собственный URIs использование схемы, Вы решили заранее, Вы не являетесь успокоительными.
- использование или не использование всех http глаголов не является действительно ограничением, и совершенно приемлемо разработать архитектуру, которая только поддерживает POST.
- Кэширование, высокое отделение, отсутствие состояния сеанса и многоуровневой архитектуры являются точками, немногие говорят о, но самое важное для успеха Архитектуры RESTful.
, Если Вы не проводите большую часть своего времени, обрабатывая Ваш формат документа, Вы, вероятно, не делаете REST.
Откровенно говоря, ответ зависит от контекста. REST и УСПОКОИТЕЛЬНЫЙ имеет значения в зависимости от того, какой язык или платформу Вы используете или что Вы пытаетесь выполнить. Так как Вы отметили свой вопрос под "веб-сервисами", я отвечу в контексте УСПОКОИТЕЛЬНЫХ веб-сервисов, который является все еще широкой категорией.
УСПОКОИТЕЛЬНЫЕ веб-сервисы могут означать что-либо от строгой интерпретации REST, где все действия сделаны строгим "УСПОКОИТЕЛЬНЫМ" способом к протоколу, который является простым XML, означая не SOAP или XMLRPC. В последнем случае это - неправильное употребление: такой протокол REST действительно "простой XML" (или "POX") протокол . В то время как протоколы REST обычно используют XML, и как таковой протоколы POX, это должно не обязательно иметь место, и инверсия не верна (справедливое, потому что XML использования протокола не делает это УСПОКОИТЕЛЬНЫМ).
Без дальнейшей суматохи, ДЕЙСТВИТЕЛЬНО УСПОКОИТЕЛЬНЫЙ API состоит из действий, взятых объекты, представленные используемым методом HTTP и URL того объекта. Действия о данных а не о том, что делает метод. Например, действия CRUD (создают, читают, обновляют и удаляют), может отобразиться на определенный набор URL и действий. Позволяет говорят, что Вы взаимодействуете с фотографией API.
- Для создания фотографии Вы отправили бы, данные через POST запрашивают к / фотографиям. Это сообщило бы, где фотография через заголовок Местоположения, например, представление/photos/12345
- To фотография, Вы использовали бы, ЗАСТАВЛЯЮТ/photos/12345
- обновлять фотографию, Вы отправили бы данные через ПОМЕЩЕННЫЙ запрос к/photos/12345.
- Для удаления фотографии Вы использовали бы, УДАЛЯЮТ/photos/12345
- Для получения списка фотографий, Вы использовали бы, ПОЛУЧАЮТ / фотографии.
Другие действия могли бы быть реализованы, как способность скопировать фотографии через запрос КОПИИ.
Таким образом, метод HTTP Вы используете карты непосредственно для намерения Вашего вызова, вместо того, чтобы отправить меры, которые Вы хотите принять как часть API. Для контрастирования неуспокоительный API мог бы использовать намного больше URL и только использовать действия POST и ПОЛУЧЕНИЕ. Так, в этом примере Вы могли бы видеть:
- Для создания фотографии отправьте POST в представление/photos/create
- To фотография, отправьте ПОЛУЧЕНИЕ в/photos/view/12345
- Для обновления фотографии, отправьте POST в/photos/update/12345
- Для удаления фотографии, отправьте ПОЛУЧЕНИЕ в/photos/delete/12345
- Для получения списка фотографий, отправьте ПОЛУЧЕНИЕ в/photos/list
, который Вы отметите, как в этом случае URL отличаются, и методы выбраны только из технической необходимости: для отправки данных необходимо использовать POST, в то время как все другое использование запросов ДОБИРАЕТСЯ.
Это означает использовать имена для идентификации и команд и параметров.
Вместо имен, являющихся простыми дескрипторами или моникерами, само имя содержит информацию. А именно, информация о том, что требуют, параметры для запроса, и т.д.
Имена не являются "корнями", а скорее действиями плюс входные данные.
Я извлек уроки больше всего из чтения статей, опубликованных на InfoQ.com: http://www.infoq.com/rest и УСПОКОИТЕЛЬНАЯ книга веб-сервисов ( http://oreilly.com/catalog/9780596529260/ ).
правовая оговорка./alex
: я связан с InfoQ.com, но эта рекомендация основана на моем собственном полезном опыте.
REST в качестве примера:
POST /user
fname=John&lname=Doe&age=25
Сервер отвечает:
200 OK
Location: /user/123
В будущем вы можете получить информацию о пользователе:
GET /user/123
Сервер отвечает:
200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>
Кому обновление:
PUT /user/123
fname=Johnny