Каковы решающие факторы при выборе представления веб-службы в качестве службы SOAP или REST?


30

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

Итак, что дает вам дополнительные издержки / сложность SOAP, когда вам это нужно и когда вы можете и должны обходиться без него?

Ответы:


17

Я реализовал REST API и мне очень понравилось. В целом, когда вы реализуете REST поверх SOAP, ваш клиент / сервер становится более ортогональным, что означает, что вы можете намного более свободно менять сервер, не затрагивая ваших клиентов. Эта ортогональность обусловлена ​​использованием более абстрактной и уже четко определенной коммуникации через HTTP-глаголы. Кроме того, использование гиперссылок, встроенных в ваши ответы REST, облегчает расширение и расширение вашего API относительно безболезненно. Предполагается, что клиенты переходят по этим встроенным ссылкам, чтобы получить доступ к новым ресурсам, как если бы человек переходил по ссылкам на веб-странице, чтобы «углубиться» для получения дополнительной информации.

С учетом сказанного у меня было несколько сотрудников, которым сказали, что они должны использовать SOAP, и они постоянно жаловались на это. Так что я начал исследовать два более подробно.

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

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


2
Вы получаете кеширование из-за парадигмы ресурса и отсутствия состояния, а не из-за HTTP.
Dietbuddha

@dietbuddha HTTP дает вам реализацию бесплатно.
Джейкоб Райл

17

Это может быть второстепенным, но REST полностью основан на HTTP.

SOAP не требует HTTP, и вы можете использовать любой транспорт, который вам нравится.

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

REST ничего не говорит вам о том, как должны выглядеть данные, которые вы отправляете и получаете. Существует WADL, но в основном вы полагаетесь на правильность документации API. SOAP имеет целый ряд технологий XML, чтобы сделать описание данных менее подверженным ошибкам. WSDL, схема ...

В конце концов, REST в основном получает файловую систему на основе HTTP. Если ваша система может вписаться в эту парадигму - тогда это может быть хорошим выбором.


+1 за упоминание нескольких транспортов. Если вам действительно нужен транспортно-независимый протокол (который, например, поддерживает работу через SMTP или аналогичный), REST отключен. Обычно HTTP достаточно хорош, однако ...
sleske

6
Я не вижу, как REST связан с HTTP? Это детали реализации. Большинство реализаций REST используют HTTP, но я не понимаю, почему я не смог реализовать REST поверх других протоколов, таких как FTP.
edalorzo

REST не ограничивает общение определенным протоколом ref: ics.uci.edu/~fielding/pubs/dis
Диссертация/

7

Итак, что дает вам дополнительные издержки / сложность SOAP, когда вам это нужно и когда вы можете и должны обходиться без него?

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

Другое отличие в том, что REST очень "ресурсный" или ориентирован на существительное . Вы взаимодействуете с ресурсами с помощью операций CRUD. Все, что не соответствует этой парадигме, становится громоздким и неловким.

SOAP, с другой стороны, является просто протоколом RPC (удаленного вызова процедур) . Это не парадигма, это просто транспортный уровень.


1
И SOAP, и REST являются лишь средствами достижения конечного результата. Они могут или не могут быть подходящими для этой задачи. Так что REST тоже можно рассматривать как транспортный уровень. Даже представление state / less не поддерживается: вы можете создавать оба варианта API - и других типов. Вы даже можете иметь двойной API, который имеет как SOAP, так и конечную точку REST. И конечная точка XML-RPC. И конечная точка Apache Thrift. И конечная точка буферов протокола Google. И что еще. В конце концов, все просто RPC.
JensG

4

REST также использует почту. Фактически при использовании REST глаголы http сообщают вам, что происходит.

REST и SOAP - это просто разные стандарты передачи данных через Интернет.

Используя оба, я обычно рекомендовал бы использовать REST, а не SOAP, если только вы не знаете, что люди, которые собираются использовать ваш веб-сервис, используют .net и Visual Studio. Как правило, гораздо проще использовать веб-сервис REST, за исключением .net VS, который выполняет большую часть работы за вас при использовании SOAP.


4
В Java также есть хорошая поддержка SOAP.

4

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


2
Согласен. SOAP является отраслевым стандартом, но чрезмерно сложным, что приводит к множеству сломанных или неполных реализаций. Кроме того, SOAP, как правило, занимает наибольшее место в плане производительности и трафика по сравнению с любым другим подходом.
JensG

1

Если вам нужно простое наглядное руководство, которое поможет вам измерить SOAP и REST в соответствии с требованиями вашего приложения ...

Виджей Прасад Гупта составил простую, полезную схему.

Прямая ссылка на блок-схему: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Ссылка на статью: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs


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

-2

Сейчас 2015 год. Я бы надеялся, что SOAP к настоящему времени уже умер, но он по-прежнему дурно пахнет. Для чего угодно, кроме самых простых «примерных» приложений, интеграция со службой SOAP сопряжена с трудностями. Это сложная архитектура, с множеством опций на нескольких уровнях в сочетании с особенностями нескольких реализаций и тонкой (и не очень тонкой) несовместимостью. У меня никогда не было ни одного хорошего опыта с этим. REST, с другой стороны, очень прост: все понимают HTTP. В большинстве случаев JSON гораздо полезнее XML InfoSet.

Чтобы дать вам представление о сложности SOAP, попробуйте интегрировать библиотеку SOAP в ваш проект. Для Java самый простой клиент Apache Axis2 (использующий простое связывание данных ADB) использует 23 новых JAR-файла. Двадцать три! 20 МБ библиотеки наворотов. CXF похож: 21 банка, когда я в последний раз считал.

Если вы действительно хотите, вы можете сделать REST с простой библиотекой HTTP.


1
это больше похоже на напыщенную речь, см. Как ответить
gnat

Вы правы. Извините, я был залит в мыльный суп в то время: D
Корнел Массон

1
У нас была такая же жалоба с CORBA / IDL еще в 90-х годах. Тогда вдруг «Простой протокол доступа к объектам» .. это будет просто! Это будет круто! Это будет быстро. Десять лет спустя это считается слишком сложным. Вместе с JSON (IMAO на самом деле является квадратным колесом для операций передачи данных в студенческих лабораторных условиях или ограниченных «я знаю, что я делаю» ситуаций быстрого исправления) и RESTful ops. Промыть, повторить ...
Дэвид Тонхофер

Я боюсь, что каждое истинное утверждение о SOAP должно читаться как напыщенная речь. Это корпоративный дизайн и дает вам множество вариантов, где вы просто хотите отправить некоторые данные. Что касается нескольких интерфейсов SOAP, с которыми я работал, то каждый из них представлял собой бесполезный беспорядок (не совсем ошибка SOAP, но сходство с SOAP коррелирует со сходством с вредоносными программами). Извините за разглагольствования.
Maaartinus
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.