REST и WS-*

Этот пост лежит у меня в черновиках уже очень давно. Все боюсь флейм нездоровый породить :-). Но все же тема мне представляется важной, и в рамках борьбы со старинными хвостами я его таки вот написал. Заранее извиняюсь, если это "и так все знают", тема действительно уже не нова.

Также должен оговориться, что я не буду подробно описывать, что такое REST сам по себе, потому что это отдельный глубокий и труднопередаваемый вопрос. Вместо этого сошлюсь например на аналогичную этой статью классика темы Джо Грегорио "REST and WS-*", там он про REST пишет более подробно. А эта статья — о том, почему REST и WS-* нельзя сравнивать, почему их все-таки сравнивают, и почему первое лучше второго. Да, никакой объективности от меня тут ждать не надо :-).

Предметная область

Речь пойдет о построении веб-сервисов: сайтов, открытых в публичный веб и явно предполагающих машинную обработку. Определение слегка общее, поэтому стоит подчеркнуть, что к ним не относится:

• сайты на вебе, предлагающие только человекочитаемый HTML-интерфейс, несмотря на то, что теоретически работу с ними можно автоматизировать
• интегрированные клиент-серверные системы, использующие для общения внутри себя протокол HTTP, но не предлагающие публичного интерфейса на вебе

REST (кратко)

Representational State Transfer — это набор общих принципов построения веб-сервисов с определенными приоритетами: масштабируемость, независимость от платформы, расширяемость. Эти принципы были сформулированы Роем Филдингом, одним из разработчиков HTTP 1.1, в своей диссертации, посвященной как раз этим вопросам.

Поскольку REST — это архитектура (или точнее "архитектурный стиль"), то в природе, по идее, не может существовать таких вещей, как "протокол REST" или "библиотека REST". Хотя библиотеки и есть, но они, на самом деле, реализуют не шарообразный REST а обычно что-то более конкретное с использованием REST-принципов. Также и с протоколом: обычно все имеют в виду самый распространенный протокол общего назначения, реализованный на REST-принципах — HTTP 1.1. Однако эти принципы можно применять и с другими протоколами, например с той же CORBA. А также эти принципы можно применять не целиком: ваша системы не обязана быть абсолютно чисто REST'овой, а может быть таковой местами.

Основной смысл REST'а, таким образом, в том, что он описывает то, в каких терминах надо думать, чтобы делать клиент-серверные системы, работающие в вебе, и не нарушающие общей экосистемы.

WS-* (кратко)

WS-* — это обобщенное название набора спецификаций, большая часть которых начинается с букв "WS" (хотя самая базовая — SOAP — с них не начинается). "WS" означает буквально "Web Services" и, надо сказать, является источником заблуждения, что веб-сервисы — это то, что построено именно на этом стеке.

Одним из приоритетов подхода, заложенного в WS-спецификации, является автоматизация публикации и доступа к объектам программных систем в виде интерфейса, доступного через HTTP. В идеале программист должен работать с чем-то на другом веб-сервисе так же прозрачно, как и с объектами в памяти его собственной программы. Пересылку данных, проверку типов и прочий сервис обеспечивает WS-*. Для достижения этого спецификации не абстрактны, а наоборот, очень конкретны и детальны, и, что важно, подразумевают не прямое программирование по описанным протоколам, а использование инструментов среды программирования, генерирующих необходимую обвязку.

Стоит добавить, что главными продвигателями WS-* являются Microsoft и IBM.

Сравнение

Из кратких описаний должно быть понятно, что впрямую сравнивать эти вещи нельзя. Во-первых, они просто разного уровня: одно — архитектурные принципы, другое — набор протоколов с реализациями. Во-вторых, они не взаимоисключающи: вполне можно делать системы на WS-* протоколах с использованием REST-принципов. У меня в голове как-то родилась аналогия, что сравнение REST и WS-* — это примерно то же, что сравнение функционального программирования и Visual Studio.

Но тем не менее... Тем не менее, сравнение все таки напрашивается, пусть даже и на эмоциональном уровне. И оно таки имеет смысл!

REST и WS-* являются ключевыми понятиями для совершенно разных подходов к созданию веб-сервисов. И неважно, что они сами находятся на разных уровнях, важно, что они подразумевают очень конкретный инструментальный стек, в рамках которого работают:

Все это нуждается в разъяснениях.

Архитектура

Архитектура REST диктует, что

• Система представляется отдельными ресурсами со своим состоянием и не хранит состояние клиентского процесса для масштабируемости.
• Ресурсы представляются стандартными mime-типами для независимости от платформы и самоописываемости.
• Ресурсы имеют универсальный интерфейс, идентифицируются собственными URL'ами и связываются только через явное указание ссылок и форм в их представлениях для обеспечения интеграции между сервисами.

WS-сервис никакой конкретной архитектурой не обладает. Снаружи — это "черный ящик", у которого есть набор специфичных методов, которые можно вызывать. Что у него внутри, известно только его разработчику. Также исключительно на совести разработчика находится масштабируемость сервиса, поскольку WS-стек тут никаких решений не подсказывает. Чаще всего поэтому WS-системы предоставляют RPC-подобный интерфейс, потому что это то, что получается само собой, если над ним особенно не задумываться.

Протоколы

Оба стека используют HTTP, но сильно по-разному.

HTTP создавался как каноническая реализация REST-принципов, и цели этой достиг. Теперь для большинства REST-ориентированных система HTTP — это все: хлеб, масло и колбаса сверху. Или более формально — и транспорт, и метаданные и сервис. А именно:

• для доступа к ресурсу используется небольшое количество методов HTTP (GET, PUT, DELETE, POST и др.) в соответствии с их изначальным смыслом
• для передачи метаданных используются HTTP-заголовки
• кеширование во всех видах обеспечивает HTTP
• проксирование — HTTP
• авторизация — тоже через HTTP, причем не только базовая, но и какая угодно другая

WS-* же использует HTTP фактически только как транспорт для передачи SOAP-вызовов. И, собственно говоря, заявляется, что HTTP для WS-* — только один из транспортов, и можно использовать другие. Для всего остального в стеке придуманы свои аналоги. В частности, SOAP-сообщение состоит из заголовков и тела, и именно эти заголовки, а не HTTPшные, имеют значение. Куча остальных фич реализована различными WS-протоколами, про которые я подробно распространяться не буду за незнанием, а лучше еще раз сошлюсь на источник.

Формат данных

Одно из основных положений REST'а — использование для описания форматов данных MIME-типов. Лучше всего, если сервис использует уже известный и описанный MIME-тип. Например, если вы выдаете какие-то календарные события, то желательно их выдавать в формате iCal с заголовком Content-type: text/calendar. Еще одна возможность — использование XHTML с микроформатами, потому что это тоже описанные данные, и под них есть парсеры. И если только совсем не получается найти подходящий MIME-тип, тогда только можно придумать свой собственный XML и очень тщательно его описать. Еще желательно его в IANA зарегистрировать, но это уж как получится :-).

WS-стек не имеет описания формата передаваемых данных в целом. Точнее, форматом является некий абстрактный SOAP-конверт, но он не означает ничего конкретного — это просто транспорт. Вместо этого описываются типы параметров, которые передаются внутри этого конверта. Строки, числа, даты. При передаче они сами по себе не связаны никакой семантикой, и что с ними делать, определяется тем, какой метод какого объекта вызывается с этими параметрами.

Это различие, в сочетании с универсальным интерфейсом, делает REST-сообщения самоописывающимися, а SOAP-сообщения — нет. Даже если оно содержит только известные типы данных, смысл его разный для каждого конкретного вызова каждого конкретного объекта.

Глобальные идентификаторы

В REST есть понятие глобального идентификатора, которым по сути является хорошо всем известный URL (точнее, URI, но разница несущественна). Прелесть его наличия в том, что он создает единый интерфейс ссылок на ресурсы между разными сервисами, которые друг про друга ничего не знают. Например, REST-сервис, работающий с картинками, может принимать к себе как непосредственно представления картинок с MIME-типом image/something, так и URL'ы картинок, которые могут быть расположены где угодно.

Еще один важный плюс — это то, что одними только URL'ам сервис может описывать свой собственный протокол. URL'ы, встречающиеся в выдаваемых представлениях ресурсов, как в телах, так и в заголовках — это новые ресурсы, в которые клиент может стучаться для того, чтобы делать с сервисом что-то еще. И поскольку формирование URL'ов является обязанностью сервиса, это позволяет ему свободно менять схему своих URL'ов, не боясь сломать клиентов, которые всегда работают только с готовыми URL'ами, а не составляют их по каким-то правилам.

В WS-стеке глобальных идентификаторов нет, так как нет самого понятия разных ресурсов. Все операции с сервисом делаются только через одну точку по уникальным для этого сервиса правилам.

Описание интерфейса

Для описание интерфейсов WS-сервисов есть развитый язык WSDL, который подробно описывает, какие у сервиса есть объекты, какие у них есть методы, и какие у них есть параметры. Формат сложный, с-трудом-человекочитаемый, и рассчитан на то, что он будет генерироваться средствами IDE автоматически по реально существующим объектам системы.

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

Стоит заметить, что WSDL в WS-стеке играет примерно ту же роль, что наличие URL'ов в REST-системах — описывает то, что можно делать с сервисом. Хотя очевидна разница в акценте. WSDL полезен клиенту по сути только для автоматической генерации стабов, и ничего не говорит о семантике вызовов. В то время как по наличию URL'ов в REST-ресурсах, описанных в подходящих местах, можно делать конкретные выводы о том, как их использовать.

Есть еще одна проблема с автоматической публикацией интерфейсов объектов наружу. Интерфейсы объектов внутри хорошо спроектированной системы гарантируют только корректность обращений к самим объектам, но не всегда определяет, в каком, грубо говоря, порядке их нужно вызывать по бизнес-логике. Например в неком форуме могут быть внутренние объекты "Топик" и "Статья", и бизнес-правило, что в топике должна быть хотя бы одна статья. Простая публикация интерфейсов объектов наружу не даст гарантии, что пользователи будут создавать статью к каждому созданному топику. Поэтому для внешнего мира обычно все равно нужно создавать отдельный слой кода, который такую логику поддерживает, и без этого одна только публикация объектов бесполезна.

Инструментарий

Инструментарий — по сути главная часть WS-стека. Его задача — создать в IDE программиста клиентского приложения удобную абстракцию для доступа к серверным объектам. Соответственно, без автоматической генерации и парсинга WSDL-описаний и SOAP-сообщений тут делать нечего. Я не возьмусь судить, насколько это все выходит удобным, но то, что выглядит это все довольно Солидным и Сложным — это точно. Есть даже точка зрения, что вся эта великая концепция была как раз и рождена для создания рынка инструментария. Большой минус у этого подхода в том, что она работает только на тех платформах, которые интересно обслуживать производителям инструментов.

Для работы с REST-системами никакого одного набора инструментов нет и быть не может. Вместо этого вам предлагается пользоваться вещами, подходящими для конкретных задач. Нужно общаться с HTTP — возьмите хорошую HTTP-библотеку, коих много. Нужна более сложная авторизация — есть библиотеки для digest-авторизации, OAuth'а и т.д. Парсинг XML, JSON и прочих форматов и подформатов — тоже в библиотеках. Каждую из таких небольших библиотек вполне может написать один человек, а не целая компания.

Культурное различие

Все технические различия в подходах, акцентах и назначениях между REST и WS-* складываются в хорошо ощутимое различие культурное.

WS-стек — это инструмент для разработчиков, которым нравится работать в среде, которую для них создает большой солидный вендор, которому они сильно доверяют. Их не беспокоят мелочные вопросы типа "как работают вещи внутри", им неважно, будет ли их сервис удобно программировать кому-то на странном маргинальном языке программирования. Им интересно, чтобы у каждой решаемой задачи уже был кем-то одобренный верный способ решения. А если он не решает задачу, то разработчик вроде как все равно не виноват — надо просто купить новую "более enterprise" версию решения, в которой это все точно уже сделано.

REST — явный любимец open source культуры. Для людей, которые не будут спать ночами, придумывая, как покрасивее описать интерфейс системы в виде stateless-ресурсов. Которым важно знать, что если им захочется написать сервис на Erlang'е, они смогут опубликовать ресурс в XML-виде, не дожидаясь, пока кто-то напишет SOAP и WSDL генераторы для Erlang'а. И которым в принципе не все равно, насколько незлым будет их сервис по отношению к другим жителям веба.

И вот поэтому я утверждаю, что:

WS-* — плохой способ делать веб-сервисы. Он решает ненужные проблемы, зато не решает нужных.

Ссылки

При написании этой статьи у меня скопилось некоторое количество ссылок по теме. Привожу их здесь в произвольном порядке:

• MochiAds - Flash Game Ad Network — распределенная система показывания рекламы в играх, использующая HTTP для связи серверных компонентов на Erlang и клиента на Python.

• REST, I just want it и Explaining REST to Damien Katz — реакции на статью Дамиена Каца о том, как он не понимает REST.

• Learning REST — подборка ссылок Тима Брея с различными объяснениями концепций REST.

• REST APIs must be hypertext-driven — недавняя нашумевшая статья Самого Филдинга о том, как многие создатели REST API не схватывают принципа ссылочности.