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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вам нужно простое наглядное руководство, которое поможет вам измерить 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

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

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

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