REST как альтернатива SOAP

Лори Маквитти

Задолго до того, как термин SOA (Service-Oriented Architecture) стал модным, а протокол SOAP — непременной частью инфраструктуры SOA, уже существовала аббревиатура REST. И хотя SOAP и все прочие WS-спецификации “украли” внимание публики у альтернативной сервис-ориентированной архитектуры, т. е. у REST, последняя становится все популярней, по мере того, как технология Web 2.0 штурмует Интернет.

Концепция REST (Representational State Transfer), детально описанная шесть лет назад Роем Томасом Филдингом в его докторской диссертации “Архитектурные стили и проектирование архитектур сетевого ПО”, позволяет резко снизить инвестиции, необходимые для обеспечения сервис-ориентированного доступа к корпоративным ресурсам. Филдинг использовал данный термин для описания техники и наилучших практик получения данных в XML-формате через HTTP с целью применения в приложениях.

И Amazon.com, и eBay используют как SOAP (Simple Object Access Protocol), так и REST API, причем в обеих компаниях REST интенсивно поддерживали с самого начала. Собственно говоря, в любой организации есть сервисы, например, имеющие дело со статическими или почти статическими ресурсами, которые могут выиграть от применения REST. Только нужно иметь в виду, что REST базируется на HTTP и наследует все хорошие и плохие аспекты этого протокола. Технология REST значительно проще, чем SOAP, но, как и HTTP, она не сохраняет состояния (stateless) и не отличается надежностью. Для критически важных сервисов SOAP, несомненно, обладает рядом важных преимуществ.

Основы

REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов. Если SOAP-клиенты запрашивают выполнение действия на сервере, то REST-клиенты попросту требуют сам ресурс. Например, вместо то-го чтобы запрашивать удаленное исполнение функции для нахождения нужного вам формуляра заказа, вы просто запрашиваете этот формуляр, примерно так же, как статичную Web-страницу.

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

И хотя может случиться так, что REST-запрос вызовет к исполнению удаленный код, создающий возвращаемый XML-отклик, однако данный факт в REST замаскирован лучше, чем у его SOAP-конкурента, который обязательно требует указания той функции, которая будет выполнена. SOAP-сервисам, как правило (хотя и не обязательно), необходим сервер приложений, такой, как WebLogic компании BEA Systems, WebSphere компании IBM или Tomcat, для разбора XML-запросов, требуемых по протоколу SOAP, и исполнения соответствующего программного кода. У REST-сервисов таких требований нет, так как желаемый ресурс явно указывается в строке URI. С REST-запросом может быть связана некая бизнес-логика, которая потребует доступа к источнику данных, или же условная логика, основанная на параметрах запроса, хотя это вовсе не обязательно и определяется исключительно внутрикорпоративными стандартами организации, проектными практиками и ограничениями на длину URI.

Популярность REST неудивительна, учитывая тот факт, что встраивание REST-сервисов в хостируемый сайт — относительно простой процесс по сравнению с усилиями, требуемыми для развертывания инфраструктуры и кода с целью поддержания SOAP-коммуникаций. Еще в 2003 г. Джефф Бар, пропагандист Web-сервисов из Amazon.com, рассказал, что его компания обрабатывает больше REST-, чем SOAP-запросов.

И del.icio.us, и Bloglines — это сайты, недавно вошедшие в сообщество социальных сетей, которые тоже обеспечивают REST-сервисы, причем ими (этими коммуникационными услугами) интенсивно пользуются люди по всему свету.

Следует также учесть, что почти все новостные каналы RSS и ATOM по сути своей являются REST-сервисами. Собственно, любой URI-запрос, предполагающий обычный XML-ответ (POX — Plain-Old XML), технически остается REST-сервисом, значит, REST-сервисы почти наверняка прямо сейчас работают в вашей организации. Проверьте и убедитесь в этом сами, мы подождем.

За и против

Пропагандисты REST-сервисов утверждают, что они лучше масштабируются и, следовательно, лучше справляются с большими объемами обслуживания. SOAP-сервисы гораздо сильнее загружают вычислительные ресурсы, поскольку требуют разбора XML-кода и упорядочивания объек-тов, — а для оптимизации управления и ускорения этих операций необходимо специальное программное и аппаратное обеспечение. Тогда как REST-сервисы попросту являются HTTP-запросами, а значит, легко контролируются штатными средствами выравнивания нагрузки обычных устройств управления трафиком уровня 7, например, от компаний Cisco Systems, Citrix и F5 Net-works. Мониторинг использования REST-сервисов тоже значительно проще и зачастую менее дорогостоящий, поскольку мониторинг на базе URI уже стал установившейся технологией; предлагаются как соответствующие коммерческие продукты, так и решения с открытым исходным кодом.

REST-сервисы проще реализовать, поскольку они базируются на хорошо известных Web-протоколах и не требуют от разработчика изучения WSDL, SOAP и массы других WS-спецификаций, используемых для управления и обеспечения безопасности SOAP-сервисов. Наипростейший REST-сервис можно реализовать за несколько минут — статичный XML-файл, возвращаемый Web-сервисом, это технически и есть REST-сервис, ведь XML-данные запрашивались через HTTP. Это вряд ли может стать оптимальным способом построения вашей сервисной инфраструктуры, но для статичных или редко меняющихся ресурсов такая возможность весьма привлекательна.

Но не все совершенно в мире REST. Поскольку технология REST базируется на HTTP, то она несет на себе отпечаток ненадежности этого протокола и невозможности сохранения состояния (его stateless-характера). Здесь-то и пригодились бы сложные WS-спецификации. Безопасный, надежный обмен сообщениями и поддержка транзакций — вот лишь некоторые задачи, решаемые в масштабе предприятия WS-спецификациями организации OASIS (этого вы не найдете для REST, как бы настойчиво ни искали).

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