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

Связанный:

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

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

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

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 обычно доступны только для чтения человеком.

Следующие ссылки предоставляют полезную информацию о 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

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

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

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

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

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

Я думаю, что интересно, что многие плюсы и минусы, которые часто упоминаются для 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, чтобы я мог быстро входить и выходить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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