WSDL против REST за и против

109

Связанный:

Зачем использовать REST вместо веб-сервисов?

При принятии решения о реализации веб-службы с использованием SOAP или REST (я имею в виду HTTP / XML в стиле RESTful), о чем мне следует знать и о чем мне думать? Я предполагаю, что это не универсальная вещь, так как мне выбрать, какой использовать.

Говард Мэй
источник
На этот вопрос также могут быть полезные ответы: stackoverflow.com/questions/90451/…
Роб Хруска,
2
Это зависит от контекста, и SOAP, и REST имеют свое место. Обычно вы не видите Hi-SOAP и lo-SOAP так, как слышите о REST. Причина в том, что существует спецификация, и либо вы следуете ей, либо нет. SOAP находит применение в центрах обработки данных, где требуется взаимодействие между различными серверами, которые не могут напрямую взаимодействовать друг с другом, и производительность является важным фактором. В таких случаях рекомендуется использовать протокол SOAP через TCP. SOAP был разработан как транспортная независимость, поэтому, по сути, вы должны иметь возможность использовать его через TCP, MSMQ и т. Д., REST работает только с HTTP.
Шрикар Додди
CodeToGlory прав. На самом деле WCF от Microsoft был разработан специально для того, чтобы сделать протокол SOAP на любом транспортном носителе таким же простым, как значение в файле конфигурации.
Travis Heseman,
Возможный дубликат SOAP и REST (различия)
Хедеши

Ответы:

112

Эти два протокола используются в реальном мире по-разному.

SOAP (с использованием WSDL) - это тяжелый стандарт XML, ориентированный на передачу документов. Преимущество этого состоит в том, что ваши запросы и ответы могут быть очень хорошо структурированы и даже могут использовать DTD. Обратной стороной является XML, и он очень подробный. Однако это хорошо, если у двух сторон должен быть строгий контракт (например, для межбанковского взаимодействия). SOAP также позволяет накладывать на документы такие вещи, как WS-Security. SOAP обычно не зависит от транспорта, что означает, что вам не обязательно использовать HTTP.

REST очень легкий и полагается на стандарт HTTP для своей работы. Это здорово - быстро запустить полезный веб-сервис. Если вам не нужно строгое определение API, это то, что вам нужно. Большинство веб-сервисов попадают в эту категорию. Вы можете изменить версию своего API, чтобы обновления API не нарушали его работу для людей, использующих старые версии (если они указывают версию). REST по существу требует HTTP и не зависит от формата (что означает, что вы можете использовать XML, JSON, HTML и т. Д.).

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

Кекоа
источник
5
@JohnSaunders Зачем нужны конверты, если нет документа? Не думаю, что я сказал, что DTD - уникальная характеристика SOAP. Я не в настроении сегодня дискутировать, извините. Возможно, перечитайте комментарии к вашему ответу на этот вопрос почти трехлетней давности. Я не думаю, что тяжелый вес - это обязательно плохо, иногда хочется Холифилда, но иногда Пакьяо справляется со своей задачей. Не
поймите
1
SOAP работает с интерфейсами в стиле документа или RPC. Кроме того, насколько мне известно, SOAP вообще не использует DTD. И вы никогда не определяли «тяжеловес». Извините, я только что увидел ваш ответ, иначе я бы проголосовал против вас три года назад.
Джон Сондерс
2
@JohnSaunders Нет проблем, хорошего дня!
Kekoa
2
REST, как и SOAP, не зависит от протокола. Он не полагается на HTTP, хотя чаще всего используется таким образом. Я думаю, что важный факт, о котором часто не упоминают, заключается в том, что SOAP vs REST сравнивают стандартный протокол w3c со свободно определенным прагматическим архитектурным шаблоном.
joelmdev
1
@ jm2 Я никогда не видел, чтобы отдых использовался вне HTTP. Мне было бы интересно посмотреть, как глаголы GET / POST / PUT / DELETE / и т. Д. работа в остальном "протоколе" без HTTP. Ссылка на сайт?
Kekoa
33

Следующие ссылки предоставляют полезную информацию о WSDL и REST, включая плюсы и минусы.

Вот пара ключевых моментов:

1) SOAP был разработан для распределенной вычислительной среды, тогда как REST был разработан для среды точка-точка.

2) WADL можно использовать для определения интерфейса для служб REST.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

Говард Мэй
источник
3
REST был разработан для распределенных систем: «[...] архитектурный стиль передачи репрезентативного состояния (REST) ​​для распределенных гипермедийных систем [...]» (Филдинг, 2000) ics.uci.edu/~fielding/pubs/dissis/ rest_arch_style.htm
Томас Эйзингер
19

Относительно WSDL (что означает «SOAP») как «тяжеловесного». Какое значение имеет тяжелое? Если набор инструментов делает всю «тяжелую работу» за вас, тогда какое это имеет значение?

Мне еще никогда не приходилось использовать сложный REST API. Когда я это сделаю, я ожидаю, что мне понадобится WSDL, который мои инструменты с удовольствием преобразуют в набор прокси-классов, чтобы я мог просто вызывать то, что кажется методами. Вместо этого я подозреваю, что для использования нетривиального API на основе REST потребуется написать вручную значительный объем «легковесного» кода.

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


Просто примечание: после этого поста у меня была возможность работать с умеренно сложным REST-сервисом. Я действительно хотел WSDL или эквивалент, и мне действительно пришлось писать много кода вручную. Фактически, значительная часть времени разработки была потрачена на устранение дублирования кода всего кода, который вызывал различные служебные операции «вручную».

Джон Сондерс
источник
Я думаю, что «легкий вес» связан с производительностью, например, чтобы загружать предлагаемые поисковые запросы по мере ввода. Я парень .NET и очень ценю некоторые функции IDE, похожие на то, что вы говорите (автоматически сгенерированные прокси-классы), но для REST ws. Такие вещи существуют?
Romias
1
Предлагаемый вами пример представляет собой простую службу REST, которую, вероятно, трудно «прочитать неправильно». Кроме того, любой, кто считает, что SOAP работает хуже, должен подкрепить это цифрами. У меня не сложилось впечатления, что фанаты REST говорили о «тяжелом весе».
Джон Сондерс,
3
Тяжелый вес не является уничижительным, я просто имел в виду, что SOAP дает вам много возможностей и имеет небольшую цену за производительность и сложность. В боксе тяжеловес, вероятно, может нанести больше вреда, чем легковес, но легковес может справиться со своей работой тогда, когда в тяжелом весе нет необходимости. Кроме того, дополнительные «вещи», такие как WS-Security или транзакции, вносят дополнительную сложность, которой просто нет в REST.
Кекоа
3
"Поддержи цифрами" - классический флеймбейт. Я поклонник обоих, но ни один из них не подходит всем.
Кекоа
4
@kekoav: Я отвечал Ромиасу, что, по его мнению, «легкий вес» важен для производительности. Я чувствовал, что это должен поддержать любой, кто так считает. Кроме того, опять же, я бы не стал предполагать лучшую производительность без ее измерения, и я бы не стал измерять, например, транзакции по сравнению с отсутствием транзакций или WS-Security по сравнению с HTTPS. Предложение проверить статус - это не приманка.
Джон Сондерс,
15

Это, вероятно, действительно относится к комментариям в нескольких из вышеперечисленных сообщений, но у меня пока нет представителя, чтобы сделать это, так что поехали.

Я думаю, что интересно, что многие плюсы и минусы, которые часто упоминаются для SOAP и REST, имеют (IMO) очень мало общего с фактическими значениями или ограничениями двух технологий. Вероятно, наиболее цитируемым преимуществом REST является то, что он «легкий» или более «читаемый человеком». На одном уровне это, безусловно, правда, REST имеет более низкий барьер для входа - требуется меньшая структура, чем SOAP (хотя я согласен с теми, кто сказал, что хорошие инструменты - это в значительной степени ответ здесь - слишком плохая часть инструментов SOAP - это довольно ужасно).

Однако, помимо этой первоначальной стоимости входа, я думаю, что впечатление REST возникает из-за комбинации формы URL-адресов запроса и сложности данных, которыми обмениваются большинство служб REST. REST имеет тенденцию поощрять более простые, более удобочитаемые URL-адреса запросов, а данные также имеют тенденцию быть более удобоваримыми. Однако в какой степени они присущи REST и в какой степени они просто случайны. Более простая структура URL-адресов является прямым результатом архитектуры, но она также может быть применена к службам на основе SOAP. Более удобоваримые данные, скорее всего, являются результатом отсутствия какой-либо определенной структуры. Это означает, что вам лучше поддерживать простые форматы данных, иначе вам придется много работать. Итак, вот дополнительная структура SOAP,

Поэтому для использования при обмене структурированными данными между компьютерными системами я не уверен, что REST по своей природе лучше, чем SOAP (или наоборот), они просто разные. Я думаю, что приведенное выше сравнение REST и SOAP с динамической и статической типизацией является хорошим. Где дианмические языки, как правило, приводят к проблемам, так это в долгосрочном обслуживании и поддержании системы (и в долгосрочной перспективе я говорю не год или два, я говорю 5 или 10). Будет интересно посмотреть, столкнется ли REST с теми же проблемами со временем. Я склонен думать, что так оно и будет, поэтому, если бы я создавал распределенную систему обработки информации, я бы предпочел SOAP в качестве механизма связи (также из-за многоуровневости и гибкости протоколов передачи и приложений, которые он предоставляет, как было упомянуто выше).

В других местах REST кажется более подходящим. Одним из основных примеров является AJAX между клиентом и его сервером (независимо от полезной нагрузки). Я не особо беспокоюсь о долговечности этого типа подключения, а простота использования и гибкость на первом месте. Точно так же, если мне нужен быстрый доступ к какой-то внешней службе, и я не думал, что буду заботиться о ремонтопригодности взаимодействия с течением времени (опять же, я предполагаю, что именно здесь REST в конечном итоге будет стоить мне больше, в одну сторону или другое), тогда я мог бы выбрать REST, чтобы я мог быстро входить и выходить.

В любом случае, это обе жизнеспособные технологии, и в зависимости от того, какие компромиссы вы хотите сделать для данного приложения, они могут служить вам хорошо (или плохо).

sfitts
источник
5

REST - это не протокол; Это архитектурный стиль. Или парадигма, если хотите. Это означает, что он гораздо менее определен, чем SOAP. Для базового CRUD вы можете опираться на стандартные протоколы, такие как Atompub, но для большинства сервисов у вас будет больше команд, чем только это.

Для потребителя SOAP может быть благословением или проклятием в зависимости от языковой поддержки. Поскольку SOAP во многом моделируется на основе строго типизированной системы, он лучше всего работает со статически типизированными языками. Для динамического языка это может легко стать непонятным и излишним. Кроме того, поддержка клиентской библиотеки не так хороша за пределами мира Java и .NET.

Troelskn
источник
Есть ли веская причина для плохой поддержки инструментов вне Java и .NET? Что-то отсутствует в файле WSDL, что могло бы помешать, скажем, созданию прокси-сервера Ruby?
Джон Сондерс,
Технически нет, но кто-то должен это реализовать, и ни Sun (извините, Oracle), ни Microsoft не собираются никому платить за реализацию клиентских библиотек на Ruby. Протокол SOAP довольно сложен. Добавьте к этому тот факт, что вся сложность заключается в системе типов, что является просто мусором с точки зрения динамического языка. Таким образом, можно сказать, что SOAP заставляет системы статических типов использовать динамические языки. В REST все наоборот.
troelskn
4

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

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

Для меня REST-сервисы почти такие же, как если бы вы создали сервлет вместо веб-сервиса SOAP. Сервлет получает данные и возвращает данные. Формат данных основан на xml. Мы также можем представить себе использование чего-то еще, кроме xml, если захотим. Например, вместо xml можно использовать теги, и это будет уже не REST, а что-то еще (может быть даже легче с точки зрения веса, потому что xml не является легким по своей природе). Назовем ли мы это по-прежнему веб-службой? Да, мы могли бы, но это не будет соответствовать какому-либо текущему стандарту, и это основная проблема здесь, если мы начнем называть все веб-сервисами, но мы можем делать это так, как мы хотим, тогда мы теряем на стороне взаимодействия вещей. Это означает, что формат данных, которыми обменивается веб-служба, больше не стандартизирован.

Что людям не нравится в SOAP, так это то, что им трудно его понять, и они не могут создавать запросы вручную. Компьютеры могут делать это очень хорошо, поэтому здесь мы должны уточнить: предполагается ли, что запросы и ответы веб-сервисов будут использоваться непосредственно конечными пользователями, или мы согласны с тем, что веб-сервисы находятся под API, вызываемым компьютерными системами на основе некоторых нормализованных стандарты?

Laize Laville
источник
1
Это больше не будет ОТДЫХОМ?
Стивен Шоу
3

МЫЛО : он также может передаваться через SMTP, это означает, что мы можем вызывать службу, используя простой текстовый формат электронной почты.

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

ОСТАЛЬНОЕ : теперь WSDL2.0 поддерживает также описание веб-службы REST.

Мы можем использовать, когда вы хотите сделать свою услугу максимально легкой, например, звонки с мобильных устройств, таких как сотовый телефон, КПК и т. Д.

Дженит Майкл Радж
источник
Спасибо, что подняли этот вопрос, @Jenith. Кажется, никто не хочет поднимать этот вопрос. WSDL имеет отношение к описанию. REST - это парадигма. Для других: см. Введение в ibm.com/developerworks/webservices/library/ws-restwsdl . Таким образом, исходный вопрос (с учетом даты ввода) показывает, что заголовок вопроса выбран плохо (вероятно, имеет в виду WSDL 1.0).
Sonny
3

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

Я бы использовал REST для приложений с выходом в Интернет для отображения интерфейсов (например, twitter api), поскольку клиенты могут использовать javascripts, html или другие, в которых ввод не является строгим. Более либеральный REST имеет больше смысла.

Также для клиентов, подключенных к Интернету (всемирная сеть), проще анализировать json или xml, выходящие из интерфейса отдыха, а не просто XML, исходящие из интерфейса мыла. сложно использовать прокси на javascript, а javascript, естественно, не поддерживает объекты. Если вы используете REST с javascript, вы обычно просто анализируете строку json, и все в порядке. Интерфейсы с выходом в Интернет обычно очень просты (поэтому в большинстве случаев это простой синтаксический анализ) и обычно не требует согласованности, поэтому REST достаточно.

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

Я пришел к выводу, что SOAP предназначен для корпоративных систем, а REST - для Интернета или WWW. Вы можете использовать его как взаимозаменяемые, но в конечном итоге вы можете столкнуться с трудностями, если не используете правильный инструмент для работы.

Извините за мой плохой английский.

Монте
источник
2

В защиту REST он строго следует принципам HTTP и адресации, например, операции чтения используют GET, операции обновления используют POST и т. Д. Я считаю, что это гораздо более чистый подход. Книга Oreilly RESTful Web Services объясняет это намного лучше, чем я. Если вы ее прочитаете, я думаю, вы предпочтете подход REST.

Ник Аллен
источник
1

Набор инструментов на стороне клиента будет одним. А знакомство с SOAP-сервисами другое. В наши дни все больше и больше сервисов переходят по маршруту RESTful, и тестирование таких сервисов может быть выполнено с помощью простых примеров cURL. Тем не менее, не так уж и сложно реализовать оба метода и обеспечить максимально широкое использование со стороны клиентов.

Если вам нужно выбрать один, я бы предложил REST, это проще.

Ахансон
источник
1

Предыдущие ответы содержат много информации, но я думаю, что есть философская разница, на которую не указывалось. SOAP был ответом на вопрос, «как создать современный объектно-ориентированный, независимый от платформы и протокола преемник RPC?». REST разрабатывался на основе вопроса «как нам воспользоваться идеями, которые сделали HTTP таким успешным для Интернета, и использовать их для распределенных вычислений?»

SOAP предоставляет вам инструменты, позволяющие сделать распределенное программирование похожим на ... программирование. REST пытается навязать стиль для упрощения распределенных интерфейсов, чтобы распределенные ресурсы могли ссылаться друг на друга, как распределенные страницы html могут ссылаться друг на друга. Один из способов сделать это - попытка (в основном) ограничить операции с ресурсами «CRUD» (создание, чтение, обновление, удаление).

REST все еще молод - хотя он ориентирован на «удобочитаемые» сервисы, он не исключает сервисов самоанализа и т. Д. Или автоматического создания прокси. Однако они не были стандартизированы (как я пишу). SOAP дает вам эти вещи, но (IMHO) дает вам «только» эти вещи, тогда как стиль, навязанный REST, уже способствует распространению веб-сервисов из-за своей простоты. Я бы сам посоветовал новичкам выбирать REST, если нет конкретных функций, предоставляемых SOAP, которые им необходимо использовать.

На мой взгляд, если вы реализуете API «с нуля» и мало знаете о возможных клиентах, я бы выбрал REST, поскольку стиль, который он поощряет, помогает сделать интерфейсы понятными и легкими для разработки. Если вы много знаете о клиенте и сервере и есть определенные инструменты SOAP, которые облегчат жизнь обоим, то я бы не стал религиозным в отношении REST.

Shaunc
источник
-1: это на самом деле не отвечает на вопрос. В нем мало или совсем ничего не сказано о том, «почему я должен выбирать одно вместо другого»?
Джон Сондерс
1
Я сконцентрировался на предоставлении информации, которую другие не делали, но добавил заключение, исходя из вашей подсказки.
shaunc
0

Вы можете легко перенести свои веб-компоненты WCF, извергающие WSDL, на другое использование, просто изменив параметры конфигурации. Вы можете использовать HTTP, а затем также именованные каналы, tcp, пользовательские протоколы и т. Д., Не изменяя код. Я считаю, что компоненты WCF также может быть проще настроить для таких вещей, как безопасность, двусторонний вызов, транзакции, параллелизм и т. Д.

REST в значительной степени ограничивает вас HTTP (что во многих случаях нормально).

Тэд Донахе
источник
0

Я знаю, что это старое обсуждение, но после прочтения всех ответов и комментариев я считаю, что все упустили самый важный момент о разнице между двумя системами: SOAP использует сложные типы, чтобы не только предоставить вам данные, но и проверить его и сохраните в строгом обозначении типа, для которого он был определен. WSDL сообщает вам, что такое формат данных, каков тип данных, позволяет вам добавлять правила стиля шаблона reg-ex и определяет, сколько раз часть данных должна быть и может быть разрешена в запросе / ответе. . В остальном же нет ни одного из этих механизмов.

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

Протокол SOAP не зависит от бизнеса, поскольку он содержит все правила данных, встроенные в документ.

Разница между SOAP и REST заключается в том, что SOAP - это автономная бизнес-ориентированная схема. REST - это текстовый документ.

СумасшедшийМерлин
источник