Материал из Wiki.
[править] Беглый взгляд на модели ответа MEP
Новые возможности, появившиеся в SOAP 1.2, позволяют более тесно связать Web-сервисы и структуру Интернет. Так, одно из нововведений – это метод GET. Этот метод имеет огромное значение, поскольку с его помощью можно выполнять разнообразную оптимизацию. Значимость GET подтверждает сам Web – достаточно вспомнить, настолько широко в нем используется данный запрос. Эта статья посвящена методу GET..
Одним из недостатков первой версии спецификации SOAP (SOAP 1.0) считалась ее зависимость от метода HTTP POST. Хотя в SOAP и использовался популярный протокол (HTTP), архитектура, на основании которой был построен протокол SOAP, вызвала достаточно нареканий..
Этот момент был учтен в новой редакции SOAP, которая была разработана под эгидой W3C. Консорциум вложил немало усилий в абстрагирование многих черт этого протокола, что должно упростить его применение среди различных технологий. В результате, в SOAP 1.2 появилась поддержка SMTP (помимо HTTP), в спецификации также улучшено использование HTTP. .
[править] О методе GET
Чем же плох POST? Если попытаться объяснить в двух словах, то HTTP определяет различные методы для взаимодействия с сервером, основными из которых являются
GET и POST. На практике GET используется для большинства запросов, тогда
как POST предназначен для форм, которые обновляют сайт. Согласно спецификации
HTTP, предназначение GET - извлечения информации, этот метод должен быть безопасным и идемпотентным..
В
данном контексте безопасный означает, что эта операция предназначены для
извлечения, а не модификации информации. Другими словами, у запроса GET
обычно не должно быть побочного действия. Идемпотентный означает, что несколько
запросов к одному и тому же унифицированному локатору (URL)
ресурса должны выдавать одинаковый результат. Приведенные определения менее
строгие, чем они могут показаться. По существу, их смысл состоит в том,
что если пользователь обращается по ссылке, он должен быть уверен, что
с его точки зрения он не изменяет ресурс..
Рассмотрим,
например, новостной сайт, информация на главной странице которого постоянно
обновляется. И хотя второй запрос вернет изменившийся блок новостей, данная
операция по-прежнему считается безопасной и идемпотентной, поскольку всегда
предоставляет текущие новости. .
В отношении запроса POST такое упрошенное рассмотрение будет некорректным. POST идентифицирует запросы, которые могут модифицировать ресурсы на сервере. В случае примера с новостным сайтом, комментарии читателя о статье должны быть реализованы с помощью запроса POST, поскольку сайт изменяется после их публикации (если, например, новое замечание располагается внизу статьи)..
Различие между GET и POST не всегда столь жёсткое, а некоторые их аспекты довольно непрозрачны. Многие сайты инкапсулируют извлечение информации в запросе POST, возможно, из-за того, что разработчики считали, что такой подход более простой..
Несмотря на то, что это обсуждение методов HTTP может показаться излишне абстрактным и теоретизированным, это далеко не так. Обеспечение оптимальной производительности браузеров и промежуточного программного обеспечения (прокси, брандмауэров и решений по доставке контента а-ля Akamai) зависит от возможности различать запросы.
[править] Объединение SOAP и GET
Первоначально SOAP поддерживал только запросы POST. Однако, Web-сервисы могут предоставлять услуги, которые безопасны согласно приведенному выше определению. Например, сервис, который запрашивает о выполнении заказа, является и безопасным, и идемпотентным. В соответствии со спецификацией HTTP, он мог бы быть реализован как запрос GET. А согласно спецификации SOAP 1.0, он должен быть POST..
В спецификации SOAP 1.2 появились модели MEP (Message Exchange Patterns, модели обмена сообщениями) и новое связывание HTTP, комбинируя которые можно реализовать Web-сервисы, которые могут отвечать на запросы GET. Модели MEP регистрируют модели взаимодействия клиента и сервера. Модель SOAP Request-Response MEP (модель запрос-ответ SOAP) – это типичное взаимодействие Web-сервиса: клиент посылает запрос на сервер, а сервер отвечает..
В этой статье подробно рассматривается модель SOAP Response MEP (модель ответа SOAP). Эта модель определяет только ответ, без запроса. На практике, это означает, что отправленный запрос не является запросом SOAP – только ответ является сообщением SOAP. При комбинировании с этим новым связыванием HTTP модель Response MEP допускает запросы GET. Ниже описано, как работает эта модель:.
- Клиент выдает запрос GET.
Чтобы запросить ответ SOAP, он присваивает заголовку Accept значение application/soap+xml.
- Cервер отвечает, и клиент
обрабатывает ответ как нормальный ответ SOAP.
Используя заголовок Accept, сервер отличает запросы SOAP от обычных запросов HTTP. Чтобы указать свои предпочтения, клиент может воспользоваться свойством q, задавая различный контент/тип в заголовке Accept..
В зависимости от своих задач клиент может включить параметры в унифицированный локатор ресурса, используя обычные методы кодирования унифицированного указателя ресурса (обычно после символа ?). Например, сервису, который сообщает статус группы серверов, возможно, и не требуются никакие параметры. По умолчанию он возвращает статус текущего сервера. И, наоборот, сервис, который сообщает о наличие продукта и его цене, должен принимать идентификатор продукта (или имя) в качестве параметра..
Разумеется, поскольку запрос не является частью SOAP, может возникнуть вопрос о том, каким образом клиент узнает, какой унифицированный локатор вызвать и какие параметры передавать. Ответ на этот вопрос прост: сервер SOAP должен делать то, что делают обычные Web-серверы, и включать этот унифицированный локатор ресурса в предыдущее взаимодействие SOAP. Ничто не мешает соединять
и сочетать GET и POST..
В качестве примера представим себе, что сервис используется для обрабатывания заказов офисных принадлежностей (ручек, бумаги, ножниц и т.п.). Этот сервис принимает такой заказ с помощью SOAP; очевидно, что подобный запрос не может считаться ни безопасным, ни идемпотентным, поэтому он отправляется
как POST. Ответ с сервера может включать унифицированный локатор ресурса, предназначенный для отслеживания выполнения этого заказа. Это отслеживание безопасно и идемпотентно, следовательно, его лучше реализовывать как GET..
[править] Axis и поддержка WSDL
На момент написания этой статьи Axis поддерживает только SOAP 1.1, хотя реализует в ограниченном виде GET. Используя его унифицированный локатор ресурса и указав параметр method и другие параметры, можно активизировать любой запрос..
Предположим, например, что автор статьи реализовал по
адресу (с унифицированным локатором ресурса) http://joker.psol.com/axis/order/Status.jws сервис, предназначенный для сообщения статуса заказа. У этого сервиса два метода
- track и detailTrack, которые принимают номер заказа ( number) в качестве параметра. Этот сервис может быть активизирован через http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322..
Язык WSDL 2.0 (разработкой которого в настоящий момент
занимается консорциум W3C) добавляет атрибут pattern в определение операций. Этот атрибут указывает, какую модель SOAP MEP поддерживает сервис (WSDL вызывает модели MEP, поэтому между SOAP и WSDL нет путаницы). Пример сервиса отслеживания приведен в Листинге 1..
[править] Листинг 1. Фрагмент WSDL
<code><operation name="track"
pattern="http://www.w3.org/2003/11/wsdl/out-only">
<output message="trackResponse"/>
</operation></code>
Простые принципы, положенные в основу Web, уже доказали свою масштабируемость и надежность. Поэтому можно только приветствовать то, что SOAP, один из главных стандартов, являющихся основой Web-сервисов, развивается в направлении, которое будет более тесно привязано к этой несомненно успешной архитектуре..
Автор рекомендует читателям, ожидающим того момента, когда в их любимых инструментальных средствах появится поддержка SOAP 1.2 и WSDL 2.0, пересмотреть свои Web-сервисы и выявить безопасные операции, являющиеся основными кандидатами на переход к связыванию GET..
INCOMERADE / Wiki / SOAP 1.2 и запрос GET
Заглавная страница
