2004 г.

SOAP 1.2 и запрос GET

Бёнуа Маршаль (Benoit Marchal)
Перевод: Intersoftlab

Беглый взгляд на модели ответа 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

<operation name="track"
   pattern="http://www.w3.org/2003/11/wsdl/out-only">
   <output message="trackResponse"/>
</operation>

Заключение

Простые принципы, положенные в основу Web, уже доказали свою масштабируемость и надежность. Поэтому можно только приветствовать то, что SOAP, один из главных стандартов, являющихся основой Web-сервисов, развивается в направлении, которое будет более тесно привязано к этой несомненно успешной архитектуре.

Автор рекомендует читателям, ожидающим того момента, когда в их любимых инструментальных средствах появится поддержка SOAP 1.2 и WSDL 2.0, пересмотреть свои Web-сервисы и выявить безопасные операции, являющиеся основными кандидатами на переход к связыванию GET.

Ресурсы

• Форум, посвященный обсуждению статей в колонке Беноита Марчала (Benoît Marchal) “XML в действии” (Working XML).
• На странице WSDL 2.0 приведена информация о ходе работ над этим языком с учетом последних изменений в SOAP.
• На странице рабочей группы XML Protocol консорциума W3C содержится подробная информация о SOAP.
• Изучив страницу HTTP, можно узнать текущую позицию W3C в отношении этого протокола.
• На сайте Брайена Д. Дэвисона (Brian D. Davison) Ресурс по Web-кэшированию и доставке контента приводится много полезной информации о кэшировании, прокси и доставке контента.
• В статье Ли Доддса (Leigh Dodds) «Когда использовать GET» (When to use GET?) рассказывается об истории включения поддержки GET в SOAP.
• Статья Расселла Бутека (Russell Butek) «Отправка и получения сообщений SOAP с JAX-RPC» (Send and receive SOAP messages with JAX-RPC) (developerWorks, сентябрь 2003г.).
• IBM WebSphere Studio Application Developer – это продукт для разработки приложений, с помощью которого можно создавать всевозможные приложения, реализующие различные технологии: XML, JSPTM, сервлеты, HTML, Web-сервисы, базы данных и EJBs.
• Множество других ресурсов в зоне XML рубрики developerWorks. Полный список статей колонки «Совет» (Tip) приведен на странице с кратким описанием этой рубрики. 
• На странице информационный бюллетень Web-cервисов/Советов по XMLможно подписаться на еженедельную рассылку новостей рубрики developerWorks.
• На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.