Каково современное значение SOAP


51

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

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

Может кто-нибудь поправить меня, если я ошибаюсь по поводу этой разницы между SOAP и REST? Кроме того, каково современное значение SOAP? Люди все еще разрабатывают новые API-интерфейсы на основе SOAP, или это в основном наследие?




14
@gnat: Как бы то ни было, ответы на оба эти вопроса ужасны.
Роберт Харви

7
Вы когда-нибудь видели сервис REST? Я вижу только «веб-сервисы, которые наконец-то узнали, что означают HTTP-глаголы». Почему мы вдруг вызываем HTTP REST?
Луаан

8
@Luaan: В этом нет ничего неожиданного; люди злоупотребляли термином «ОТДЫХ» годами.
Легкость гонки с Моникой

Ответы:


59

ОТДЫХ - это действительно архитектурный стиль. SOAP - это протокол данных. Различие важно; Вы не можете сравнить их напрямую.

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

Обратите внимание, что вам на самом деле не нужен REST для создания отношений клиент / сервер между двумя компьютерами в Интернете. Все, что вам нужно, - это механизм, который передает JSON или XML, и вам это даже не нужно, если вы хотите быть несовместимыми со всеми остальными.

Тем не менее, SOAP потерял популярность для новых общедоступных API-интерфейсов, хотя он все еще широко используется для приложений B2B, поскольку с ним можно определить «контракт данных». Веб-сервисы JSON обладают тем преимуществом, что они довольно легкие и гибкие, и, поскольку Javascript распознает JSON изначально, это естественный выбор для браузеров.

Но на самом деле все это не имеет ничего общего с REST.

Дальнейшее чтение
REST лучше, чем SOAP? (хорошая статья, даже если она неправильно называет REST протоколом).
Модель зрелости Ричардсона


3
Я бы сказал, что убийственная особенность веб-сервисов JSON заключается именно в том, что браузеры плохо поддерживают XML и SOAP, в то время как у них есть (почти) встроенная поддержка JSON. У SOAP есть много возможностей, но если вы не можете делать запросы AJAX против службы SOAP, он мертв. Javascript / JSON стал наименьшим общим знаменателем в Интернете, так что вам нужно огромное преимущество , чтобы не использовать его, и SOAP не что намного лучше.
Луаан

3
@Luaan Я бы не сказал, что браузеры плохо поддерживают XML. На самом деле, трудно добиться чего-то лучшего, чем выполнить XML- запрос HttpRequest и получить доступ к атрибуту с анализируемым DOM. Просто если вам нужна типичная структура данных, а не документ, JSON просто более подходит, будь то браузер или любая другая среда.
Андре Парамес,

4
Все, что вам нужно, - это механизм, который передает JSON или XML, и вам это даже не нужно, если вы хотите быть несовместимыми со всеми остальными. -1: если вы хотите соединить клиент и сервер, вам нужен произвольный протокол, который обе стороны понимают, что он не имеет никакого отношения к использованию XML, JSON или совместимости со всеми остальными. Даже использование JSON или XML не гарантирует, что вы совместимы со всеми или даже с кем-то. Json и xml - это просто форматы данных.
Павел Василевский

6
@PaulWasilewski: Да, это то, что я сказал. Не зацикливайтесь на словах. Есть причина, по которой все используют JSON; это стандарт. Использование этого гарантирует, что вы используете то, что узнаваемо для других.
Роберт Харви

3
@RobertHarvey, нет, это не то, что ты написал, может быть, ты это имел в виду. JSON стандартный и что? CSV, Protcol Buffers, BSON стандартизированы, как и многие другие. Так что причина, по которой все используют JSON, многообразна. И есть даже те, кто использует JSON, потому что все используют JSON;)
Пол Василевский,

29

REST гораздо более ограничен, чем SOAP, что является его сильной стороной и причиной его популярности.

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

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

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


4
Старые добрые дебаты о статической и динамической типизации, ура: D Аккуратная и трудная против хакерская и простая, война, которая никогда не заканчивается.
Луаан

@Luaan ... и динамический всегда выигрывает для обмена данными. youtube.com/watch?v=ROor6_NGIWU
Джаред Смит

6
@JaredSmith Я категорически не согласен. Предполагается, что контракты соблюдаются, поэтому обе конечные точки правильно отображают данные, если вы можете сделать это с помощью публикации метаданных вместо страниц документации, подверженных ошибкам, почему бы вам не сделать это?
drake7707

1
Практическое ОТДЫХ - это протокол; Тезис и религия являются «архитектурным стилем». Этот ответ правильно сравнивает практический отдых с практичным мылом.
bmargulies

1
Ваш ответ уже показал, что вы не понимаете REST, и ваш комментарий подчеркивает это.
Павел Василевский

5

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

К сожалению, REST стал разговорным синонимом службы RESTful HTTP, что означает реализацию архитектуры в стиле REST с протоколом HTTP как (приложение).

REST основан на следующих принципах (ограничениях и элементах) (в скобках - реализация в RESTful HTTP) [1] .

  • Stateless (HTTP - протокол без сохранения состояния)
  • Ресурс (идентифицируется по URI)
  • Унифицированный интерфейс (методы HTTP)
  • Представление (MIME-TYPE)
  • HATEOS (Гиперссылки)
  • Кэш (HTTP Cache)

С другой стороны, многие имеют в виду, что SOAP - это веб-сервис, основанный на WSDL и SOAP, которые являются частью архитектуры веб-сервиса W3C [2] .

  • SOAP используется в качестве протокола для обмена информацией (в основном, имя метода, параметры, возвращаемые значения, типы данных, ...).
  • WSDL язык определения интерфейса для описания веб-сервиса.

Каково современное значение SOAP *?

SOAP является стандартом W3C и используется в качестве формата обмена информацией в веб-сервисах W3C. Эти веб-сервисы были - особенно во время ажиотажа SOA (сервис-ориентированных архитектур) примерно в 2008 году (+ - 3 года) - и (к сожалению) до сих пор используются в основном в корпоративных приложениях.

Это имеет несколько причин. Тогда RESTful HTTP не был известен, и его неправильно поняли. К сожалению, это все еще неправильно поняли, посмотрите на другие ответы

«[...] REST гораздо более ограничен, чем SOAP [...].»

«Основная цель REST - представлять ресурсы в Интернете [...].»

Кроме того, SOAP (и WSDL) являются частью стека протоколов веб-службы W3C, который обеспечивает еще больше стандартов для реализации веб-службы.

Люди все еще разрабатывают новые API-интерфейсы на основе SOAP, или это в основном наследие?

Так что да, есть еще и будут будущие системы, которые используют SOAP (по крайней мере, в корпоративных системах, в основном за дверями). Но большинство сейчас пытается сделать что-то вроде «ОТДЫХА».

Может кто-нибудь поправить меня, если я ошибаюсь по поводу этой разницы между SOAP и REST?

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

Как я уже писал, вы не можете сравнить их. Но вы можете сравнить веб-службу RESTful HTTP с веб-службой SOAP / WSDL.


«Но вы можете сравнить веб-службу RESTful HTTP с веб-службой SOAP / WSDL». Но это то, что спрашивает ОП. Кто-нибудь еще ответил на это?
RoboJ1M
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.