После написания первой части статьи аппетит разыгрался и захотелось продолжить изучение, на этот раз больше с уклом в практическую часть. Весь сыр-бор у нас разгорелся из-за необходимости взаимодействии приложений и платформ, поэтому именно этому в основном и будет посвящена статья.
REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?
Зачем вообще нужно взаимодействие приложений, тем более написанных на разных платформах? Глупый вопрос, конечно. В мире программирования параллельно существуют и развиваются несколько абсолютно независимых, а местами и враждующих платформ. Кроме того, огромное количество софта уже написано и успешно работает, поэтому переписывать его под каждую новую платформу никто не будет. Возьмем банк для примера. Все in-house программисты банка всегда писали на JAVA, поэтому у банка есть сервис, который уже 5 лет прекрасно работает, недавно появились красивые мобильные приложения на Android, которые стабильно работают почти на всех версиях ОС, и остался даже сайт с апплетом, которых преподаватели в харьковских вузах до сих показывают в качестве примера передовых веб-технологий (jk). А теперь появилась задача разработки десктопного банковского приложения под Windows. Банк заказал WPF-приложение аутсорсинговой компании. Как же организовать общение платформ?
Отвлечемся пока от примера и обратимся к истории. Мне это делать, наверное, сложнее, чем многим из моих коллег, потому что я вступил в секту программистов во времена .Net, когда не обязательно знать протокол HTTP, чтобы писать сайты, а писать полнофункциональные десктопные приложения можно даже ни разу не слышав о WinAPI. Но я попробую сделать такой экскурс. Времена динозавров особо рассматривать не будем (будем считать, что динозавры вымерли с появлением XML в 1998), чтобы не отдаляться от основной темы. Предположим, у нас есть установленное соединение между двумя приложениями, по которому один может посылать байты, а другой будет их получать. Что дальше? Приложения должны договориться, что, к примеру, «1» значит «вышли список всех клиентов», «2|36782» — «вышли список транзакций для клиента 36782». Возможно, примерно так происходило дело в расцвет Мезозойской Эры. Это обязывало разработчиков изобретать новый велосипед для каждого взаимодействия приложений. С развитием интернета (середина 90-х) приложения смогли обмениваться информацией, предоставляя ее в оговоренном виде по оговоренному URL (позже это назовут “REST”). Какие протоколы были и как приложения общались до появления XML-RPC – писать не буду, просто потому что мало что знаю, может быть у кого-нибудь в комментариях пробьются ностальгические чувства.
RPC – это «remote procedure call», понятие очень старое, объединяющие древние, средние и современные протоколы, которые позволяют вызвать метод в другом приложении. XML-RPC – это протокол, появившийся в 1998, вскоре после появления XML. Изначально поддерживался Microsoft, но вскоре Microsoft полностью переключилась на SOAP и поэтому в .Net Framework мы не найдем классов для поддержки этого протокола. Несмотря на это, XML-RPC продолжает жить до сих пор в различных языках (особенно в PHP), видимо, заслужил любовь разработчиков своей простотой. Интересное чувство, когда наконец-то разбираешься в том, о чем уже давно писал в резюме. Это про XML-RPC и мое еще студенческое резюме. :)
SOAP также появился в 1998 году стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft, было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время были и те, кто считал SOAP настоящим прорывом. Сам же протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 года W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас является последним. Семейство у SOAP получилось внушительное, вот их семейная фотография:
(на фото — WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On… А того второго справа вообще не вспомнить, как зовут)
За более десяти лет споры по поводу SOAP не утихли, он по прежнему яростно критикуется за перегруженность, за низкую скорость работы. Однако протокол не умер, скорее даже наоборот, хотя и мир тоже не захватил. Критика протокола во многом справедлива: не используются заложенные в HTTP фичи, длина сообщений больше, чем у REST, от всех этих WS-Federation и WS-AtomicTransaction часто нету никакой пользы.
Но я хочу заострить внимание на другом – как же быстро можно разрабатывать распределенные приложения, используя семейство протоколов SOAP! Это ли не революция, которую нам обещал Microsoft? По-моему, это именно она. Где еще можно порасставлять аттрибуты в коде, нажать кнопку Publish на сервисе, нажать кнопку Generate Proxy на клиенте и вызывать код, как будто он находится в том же проекте? Поэтому на передний план выходит вопрос о том, в каких языках и средах программирования такая сказка возможна. Попробую свести эти данные в таблицу:
Несмотря на все лестные слова с адрес в адрес SOAP, я ни в коем случае не собираюсь сказать, что REST подход не нужен. Термин REST появился в 2000, т.е. всего лишь на два года позже первой версии SOAP. Сам же подход появился намного раньше, в 2000 же он просто был осознан, задокументирован и название сменилось с длинного «я тебе даю такую-ту инфу там-то» на непонятное «REST». Происхождение названия и принципы REST подробно обсуждались в первой части статьи. Здесь я заострю внимание на том, где REST лучше использовать и почему:
А когда же использовать SOAP:
Таким образом, у меня все свелось к тому, что использовать SOAP надо там, где он поддерживается, в противном случае использовать REST. Это в разы сократит время разработки клиентов веб-сервиса и внесения изменений в них, позволит вместо детального разбора кода и добавления туда новых полей просто нажать кнопку «Update Service Reference».
Скорость разработки REST и SOAP сервисов в .Net одинакова. В WCF вообще можно превратить SOAP-сервис в RESTful и наоборот путем нехитрых и не трудоемких махинаций с конфигурацией, поэтому, говоря об ускорении скорости разработки, я имею ввиду клиентскую часть, которая может разрабатываться как одновременно с серверной частью, так и намного позже и совсем другой компанией. Польза от использования SOAP увеличивается, если сервис принимает и возвращает большие и сложные структуры данных.
Сейчас REST и SOAP оба успешно используются, однако может произойти так, что SOAP действительно исчезнет, как пишут его критики. Такое, по моему мнению, возможно, если для RESTful сервисов начнет использоваться WSDL или подобный протокол, который позволит генерировать клиентские прокси. Поползновения такие были, протокол назывался WADL, однако на данный момент ничего такого не существует. Конечно, для такого сценария потребуется желание и приличные усилия хотя бы одного из основных игроков в мире IT, но я бы не стал исключать такой вариант. И будет у нас тогда лучшее из двух миров – простота и бенефиты от архитектуры сети и автоматизация взаимодействия приложений с помощью клиентских прокси.
Все уже забыли о примере из начала статьи? Он взят из жизни. Напомню, там разрабатывается WPF приложение, которое должно получать данные из существующего сервиса, написанного на JAVA. В каком формате он мог бы нам отдавать данные чтобы все выглядело бы красиво в соответствии с этой статьей? Правильно, в SOAP. А он отдает json. Надеюсь, ни у кого не возникло мысли «какой json, это в смысле REST?». Конечно REST! REST может возвращать данные в простом XML, json или любом другом запрошенном формате, даже в формате «как Вася попросил», если вам конечно удастся сделать этот формат одним рекомендуемых стандартов W3C или хотя бы договориться с разработчиками сервиса, чтобы они знали, что делать с этим:
Мы отвлеклись от дела. Ну возвращает сервис данные в json, и чем это нам грозит? А вот чем: прокси клиента сгенерить не сможем, придется вручную посылать запросы и парсить ответы. Придется использовать HttpWebRequest или надстройки над ним. А был бы SOAP – деньги заказчика были бы сэкономлены.
Надеюсь, мне удалось обрисовать достаточно целостную картину взаимодействия приложений вне зависимости от языка и платформы. Хотел добавить, что описанные три подхода (REST, XML-RPC, SOAP) – это не все возможные варианты. Например, игрушки для соцсетей (пишутся на Flex) часто устанавливают прямое соединение через сокеты с серверной частью, написанной на C#. За счет этого получается выигрыш в скорости вместе с необходимостью изобретать мопед для каждого нового приложения. Где-то это уже было…
Вполне возможно, что я упустил что-то важное, особенно если это не касается .Net, буду рад узнать об этом.
P.S. Спасибо int03e, SSSurkv и 1nd1go за то, что повысили мне вчера карму, чтобы я мог опубликовать эту статью.
Оглавление цикла статей:
REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?
Зачем все это?
Зачем вообще нужно взаимодействие приложений, тем более написанных на разных платформах? Глупый вопрос, конечно. В мире программирования параллельно существуют и развиваются несколько абсолютно независимых, а местами и враждующих платформ. Кроме того, огромное количество софта уже написано и успешно работает, поэтому переписывать его под каждую новую платформу никто не будет. Возьмем банк для примера. Все in-house программисты банка всегда писали на JAVA, поэтому у банка есть сервис, который уже 5 лет прекрасно работает, недавно появились красивые мобильные приложения на Android, которые стабильно работают почти на всех версиях ОС, и остался даже сайт с апплетом, которых преподаватели в харьковских вузах до сих показывают в качестве примера передовых веб-технологий (jk). А теперь появилась задача разработки десктопного банковского приложения под Windows. Банк заказал WPF-приложение аутсорсинговой компании. Как же организовать общение платформ?
Немного истории
Отвлечемся пока от примера и обратимся к истории. Мне это делать, наверное, сложнее, чем многим из моих коллег, потому что я вступил в секту программистов во времена .Net, когда не обязательно знать протокол HTTP, чтобы писать сайты, а писать полнофункциональные десктопные приложения можно даже ни разу не слышав о WinAPI. Но я попробую сделать такой экскурс. Времена динозавров особо рассматривать не будем (будем считать, что динозавры вымерли с появлением XML в 1998), чтобы не отдаляться от основной темы. Предположим, у нас есть установленное соединение между двумя приложениями, по которому один может посылать байты, а другой будет их получать. Что дальше? Приложения должны договориться, что, к примеру, «1» значит «вышли список всех клиентов», «2|36782» — «вышли список транзакций для клиента 36782». Возможно, примерно так происходило дело в расцвет Мезозойской Эры. Это обязывало разработчиков изобретать новый велосипед для каждого взаимодействия приложений. С развитием интернета (середина 90-х) приложения смогли обмениваться информацией, предоставляя ее в оговоренном виде по оговоренному URL (позже это назовут “REST”). Какие протоколы были и как приложения общались до появления XML-RPC – писать не буду, просто потому что мало что знаю, может быть у кого-нибудь в комментариях пробьются ностальгические чувства.
RPC
RPC – это «remote procedure call», понятие очень старое, объединяющие древние, средние и современные протоколы, которые позволяют вызвать метод в другом приложении. XML-RPC – это протокол, появившийся в 1998, вскоре после появления XML. Изначально поддерживался Microsoft, но вскоре Microsoft полностью переключилась на SOAP и поэтому в .Net Framework мы не найдем классов для поддержки этого протокола. Несмотря на это, XML-RPC продолжает жить до сих пор в различных языках (особенно в PHP), видимо, заслужил любовь разработчиков своей простотой. Интересное чувство, когда наконец-то разбираешься в том, о чем уже давно писал в резюме. Это про XML-RPC и мое еще студенческое резюме. :)
SOAP
SOAP также появился в 1998 году стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft, было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время были и те, кто считал SOAP настоящим прорывом. Сам же протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 года W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас является последним. Семейство у SOAP получилось внушительное, вот их семейная фотография:
(на фото — WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On… А того второго справа вообще не вспомнить, как зовут)
За более десяти лет споры по поводу SOAP не утихли, он по прежнему яростно критикуется за перегруженность, за низкую скорость работы. Однако протокол не умер, скорее даже наоборот, хотя и мир тоже не захватил. Критика протокола во многом справедлива: не используются заложенные в HTTP фичи, длина сообщений больше, чем у REST, от всех этих WS-Federation и WS-AtomicTransaction часто нету никакой пользы.
Но я хочу заострить внимание на другом – как же быстро можно разрабатывать распределенные приложения, используя семейство протоколов SOAP! Это ли не революция, которую нам обещал Microsoft? По-моему, это именно она. Где еще можно порасставлять аттрибуты в коде, нажать кнопку Publish на сервисе, нажать кнопку Generate Proxy на клиенте и вызывать код, как будто он находится в том же проекте? Поэтому на передний план выходит вопрос о том, в каких языках и средах программирования такая сказка возможна. Попробую свести эти данные в таблицу:
А как же REST, неужели он не нужен?
Несмотря на все лестные слова с адрес в адрес SOAP, я ни в коем случае не собираюсь сказать, что REST подход не нужен. Термин REST появился в 2000, т.е. всего лишь на два года позже первой версии SOAP. Сам же подход появился намного раньше, в 2000 же он просто был осознан, задокументирован и название сменилось с длинного «я тебе даю такую-ту инфу там-то» на непонятное «REST». Происхождение названия и принципы REST подробно обсуждались в первой части статьи. Здесь я заострю внимание на том, где REST лучше использовать и почему:
- В сервисах, которые будут использоваться из javascript. Тут и говорить нечего, javascript хорошо работает с json, поэтому именно его и надо предоставлять.
- В сервисах, которые будут использоваться из языков, в которых нет возможности сгенерировать прокси клиента. Это Objective-C, например. Не нужно парсить вручную SOAP-конверт, это незачем.
- Когда существуют очень высокие требования к производительности. Это, как правило, очень интенсивно используемые API, вроде Twitter API или Google API.
А когда же использовать SOAP:
- Когда взаимодействие происходит между платформами, под которые существуют инструменты для ускорения разработки с использованием SOAP. Например, правильно писать SOAP-сервис на JAVA, который будет использоваться из .Net и Flex.
- Когда можно извлечь пользу из всех накруток SOAP. Достоверных сведений о том, что кто-то сумел это сделать, у меня нет. Понятный пример придумать не могу.
Таким образом, у меня все свелось к тому, что использовать SOAP надо там, где он поддерживается, в противном случае использовать REST. Это в разы сократит время разработки клиентов веб-сервиса и внесения изменений в них, позволит вместо детального разбора кода и добавления туда новых полей просто нажать кнопку «Update Service Reference».
Скорость разработки REST и SOAP сервисов в .Net одинакова. В WCF вообще можно превратить SOAP-сервис в RESTful и наоборот путем нехитрых и не трудоемких махинаций с конфигурацией, поэтому, говоря об ускорении скорости разработки, я имею ввиду клиентскую часть, которая может разрабатываться как одновременно с серверной частью, так и намного позже и совсем другой компанией. Польза от использования SOAP увеличивается, если сервис принимает и возвращает большие и сложные структуры данных.
Дни SOAP сочтены?
Сейчас REST и SOAP оба успешно используются, однако может произойти так, что SOAP действительно исчезнет, как пишут его критики. Такое, по моему мнению, возможно, если для RESTful сервисов начнет использоваться WSDL или подобный протокол, который позволит генерировать клиентские прокси. Поползновения такие были, протокол назывался WADL, однако на данный момент ничего такого не существует. Конечно, для такого сценария потребуется желание и приличные усилия хотя бы одного из основных игроков в мире IT, но я бы не стал исключать такой вариант. И будет у нас тогда лучшее из двух миров – простота и бенефиты от архитектуры сети и автоматизация взаимодействия приложений с помощью клиентских прокси.
Пример
Все уже забыли о примере из начала статьи? Он взят из жизни. Напомню, там разрабатывается WPF приложение, которое должно получать данные из существующего сервиса, написанного на JAVA. В каком формате он мог бы нам отдавать данные чтобы все выглядело бы красиво в соответствии с этой статьей? Правильно, в SOAP. А он отдает json. Надеюсь, ни у кого не возникло мысли «какой json, это в смысле REST?». Конечно REST! REST может возвращать данные в простом XML, json или любом другом запрошенном формате, даже в формате «как Вася попросил», если вам конечно удастся сделать этот формат одним рекомендуемых стандартов W3C или хотя бы договориться с разработчиками сервиса, чтобы они знали, что делать с этим:
Content-Type: application/as-Vasya-asked; charset=utf-8
Мы отвлеклись от дела. Ну возвращает сервис данные в json, и чем это нам грозит? А вот чем: прокси клиента сгенерить не сможем, придется вручную посылать запросы и парсить ответы. Придется использовать HttpWebRequest или надстройки над ним. А был бы SOAP – деньги заказчика были бы сэкономлены.
Заключение
Надеюсь, мне удалось обрисовать достаточно целостную картину взаимодействия приложений вне зависимости от языка и платформы. Хотел добавить, что описанные три подхода (REST, XML-RPC, SOAP) – это не все возможные варианты. Например, игрушки для соцсетей (пишутся на Flex) часто устанавливают прямое соединение через сокеты с серверной частью, написанной на C#. За счет этого получается выигрыш в скорости вместе с необходимостью изобретать мопед для каждого нового приложения. Где-то это уже было…
Вполне возможно, что я упустил что-то важное, особенно если это не касается .Net, буду рад узнать об этом.
P.S. Спасибо int03e, SSSurkv и 1nd1go за то, что повысили мне вчера карму, чтобы я мог опубликовать эту статью.