SOAP или REST для веб-служб?

Это нюанс.

Если вам нужно иметь интерфейс других систем с вашими службами, то многие клиенты будут более довольны SOAP из-за уровней «проверки», которые у вас есть с контрактами, WSDL и стандартом SOAP.

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

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

Мне любопытно, что думают другие.

Если вы ищете возможность взаимодействия между разными системами и языками, я определенно выберу REST. Например, у меня было много проблем, пытаясь заставить SOAP работать между .NET и Java.

Не упускайте из виду XML-RPC. Если вам просто нужно легкое решение, то есть много чего сказать о протоколе, который может быть определен на нескольких страницах текста и реализован с минимальным объемом кода. XML-RPC существует уже много лет, но на какое-то время вышел из моды, но в последнее время его минимализм, похоже, возрождает.

МЫЛО в настоящее время имеет преимущество в виде более совершенных инструментов, в которых они будут генерировать много шаблонного кода как для уровня обслуживания, так и для генерации клиентов из любого заданного WSDL.

ОТДЫХ проще, в результате его легче поддерживать, он лежит в основе веб-архитектуры, обеспечивает лучшую видимость протокола и, как было доказано, масштабируется при размере самой WWW. Некоторые фреймворки помогают создавать службы REST, например Ruby on Rails, а некоторые даже помогают в написании клиентов, например службы данных ADO.NET. Но по большей части отсутствует поддержка инструментов.

REST - это архитектура, SOAP - это протокол.

Это первая проблема.

Вы можете отправлять конверты SOAP в приложении REST.

Сам по себе протокол SOAP на самом деле довольно прост и прост, но стандарты WSS- * делают его очень сложным.

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

Если ваши потребители, скорее всего, будут клиентами RIA или Ajax, вам, вероятно, понадобится что-то более простое, чем SOAP, и более родное для клиента (особенно JSON).

Пакеты JSON, отправляемые через HTTP, не обязательно являются архитектурой REST, это просто сообщения для URL-адресов. Все это прекрасно работает, но в идиоме REST есть ключевые компоненты. Однако их легко спутать. Но то, что вы говорите о HTTP-запросах, не обязательно означает, что у вас есть архитектура REST. У вас может быть приложение REST без HTTP (помните, это редко).

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

REST - это принципиально отличная от SOAP парадигма. Хорошее прочтение REST можно найти здесь: Как я объяснил ОТДЫХ жене.

Если у вас нет времени читать, вот краткая версия: REST - это своего рода сдвиг парадигмы, сосредоточив внимание на «существительных» и ограничив количество «глаголов», которые вы можете применить к этим существительным. Разрешены только глаголы «получить», «положить», «опубликовать» и «удалить». Это отличается от SOAP, где множество разных глаголов можно применять к множеству разных существительных (то есть ко многим различным функциям).

Для REST четыре глагола сопоставляются с соответствующими HTTP-запросами, а существительные идентифицируются URL-адресами. Это делает управление состоянием намного более прозрачным, чем в SOAP, где часто неясно, какое состояние находится на сервере, а что на клиенте.

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

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

REST хорошо работает с веб-страницами AJAX'ы. Если ваши запросы будут простыми, вы можете выполнять вызовы сервисов прямо из вашего JavaScript, и это очень удобно. Старайтесь избегать использования каких-либо пространств имен в XML-ответе, я видел, как браузеры подавляются ими. Итак, xsi: type, вероятно, вам не подойдет, никаких слишком сложных XML-схем.

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

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

Мой процесс принятия решений следующий: если я хочу, чтобы мой сервис легко настраивался потребителями, а сообщения, которые я пишу, будут среднего или маленького размера (10 МБ или меньше), и я не против сжечь дополнительный процессор циклы на сервере, я использую SOAP. Если мне нужно обслуживать AJAX в веб-браузерах, или мне нужно что-то для потоковой передачи, или мои ответы огромны, я перехожу в REST.

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

Я уверен, что Дон Бокс создал SOAP в шутку - «послушайте, может вызывает методы RPC через Интернет», и сегодня стонет, когда он понимает, каким раздутым кошмаром веб-стандартов это стало :-)

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

Я построил один из первых серверов SOAP, включая генерацию кода и генерацию WSDL, на основе исходной спецификации, которая разрабатывалась, когда я работал в Hewlett-Packard. Я НЕ рекомендую использовать SOAP ни для чего.

Аббревиатура «мыло» - ложь. Это не просто, он не объектно-ориентированный, он не определяет правил доступа. Это, пожалуй, протокол. Это худший спекулянт Дона Бокса, и это настоящий подвиг, поскольку именно он устроил «COM».

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

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

Я бы порекомендовал вам сначала использовать REST - если вы используете Java, посмотрите JAX-RS и реализацию Джерси. REST намного проще и удобнее взаимодействовать со многими языками.

Как уже говорили другие в этом потоке, проблема с SOAP заключается в его сложности, когда появляются другие спецификации WS- *, и возникает бесчисленное множество проблем с взаимодействием, если вы отклоняетесь от неправильных частей WSDL, XSD, SOAP, WS-Addressing и т. д.

Лучший способ судить о дебатах REST и SOAP - это посмотреть в Интернете - почти все крупные игроки в веб-пространстве, google, amazon, ebay, twitter и др., Как правило, используют и предпочитают RESTful API, а не SOAP.

Другой приятный подход к использованию REST заключается в том, что вы можете повторно использовать большой объем кода и инфраструктуры между веб-приложением и интерфейсом REST. например рендеринг HTML вместо XML или JSON ваших ресурсов обычно довольно просто с такими фреймворками, как JAX-RS и неявные представления, плюс его легко работать с ресурсами RESTful с помощью веб-браузера

Послушайте этот подкаст, чтобы узнать. Если вы хотите узнать ответ, не слушая, тогда ОК, его ОТДЫХ. Но я действительно рекомендую послушать.

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

(otoh, можете ли вы использовать файлы cookie со службой REST для отправки внеполосных данных типа «заголовок»?)

Большинство приложений, которые я пишу, являются серверными приложениями C# или Java или настольными приложениями в WinForms или WPF. Этим приложениям, как правило, требуется более богатый сервисный API, чем может предоставить REST. Кроме того, я не хочу тратить больше пары минут на создание своего клиента веб-службы. Инструменты создания клиентов обработки WSDL позволяют мне реализовать своего клиента и перейти к добавлению ценности для бизнеса.

Теперь, если бы я писал веб-службу явно для некоторых javascript-вызовов ajax, она, вероятно, была бы в REST; просто ради знания клиентских технологий и использования JSON. На мой взгляд, API-интерфейсы веб-сервисов, используемые из javascript, вероятно, не должны быть очень сложными, поскольку этот тип сложности, по-видимому, лучше обрабатывается на стороне сервера.

С учетом сказанного, есть несколько клиентов SOAP для javascript; Я знаю, что у jQuery он есть. Таким образом, SOAP может можно использовать из javascript; просто не так хорошо, как служба REST, возвращающая строки JSON. Поэтому, если бы у меня была веб-служба, которую я хотел бы сделать достаточно сложной, чтобы она была гибкой для произвольного количества клиентских технологий и применений, я бы выбрал SOAP.

Я знаю, что это старый вопрос, но я должен опубликовать свой ответ - может быть, кому-то он будет полезен. Я не могу поверить, сколько людей рекомендуют REST вместо SOAP. Я могу только предположить, что эти люди не являются разработчиками или никогда не реализовывали службы REST любого разумного размера. Реализация службы REST занимает НАМНОГО больше времени, чем реализация службы SOAP. И, в конце концов, это тоже получается намного запутаннее. Вот причины, по которым я бы выбрал SOAP в 99% случаев:

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

2) Зачем вообще писать службу REST, которая возвращает XML? Единственное отличие состоит в том, что с REST вы не знаете типы, которые представляет каждый элемент / атрибут - вы можете реализовать его самостоятельно и надеетесь, что однажды строка не встретится в поле, которое, как вы думали, всегда было int. SOAP определяет структуру данных с помощью WSDL, так что это не проблема.

3) Я слышал жалобу, что с SOAP у вас есть «накладные расходы» SOAP Envelope. В наши дни действительно ли нам нужно беспокоиться о горстке байтов?

4) Я слышал аргумент, что с помощью REST вы можете просто вставить URL-адрес в браузер и просмотреть данные. Конечно, если ваша служба REST использует простую аутентификацию или нет. Например, служба Netflix использует протокол OAuth, который требует от вас подписывать и кодировать вещи, прежде чем вы даже сможете отправить свой запрос.

5) Зачем нам нужен «читаемый» URL для каждого ресурса? Если бы мы использовали инструмент для реализации службы, действительно ли нам важен фактический URL-адрес?

Мне нужно идти?

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

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

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

С точки зрения бизнеса это, похоже, оставляет общение открытым для интерпретации и изменения, что кажется плохой идеей.

Верхний «Ответ» в этом потоке, кажется, говорит, что SOAP означает простой объектно-ориентированный протокол доступа, однако, глядя на вики, O означает, что объект не объектно-ориентированный. Это разные вещи.

Я знаю, что этот пост очень старый, но подумал, что должен ответить своими собственными выводами.

REST - это архитектура, изобретенная Роем Филдингом и описанная в его диссертации Архитектурные стили и проектирование сетевых архитектур программного обеспечения. Рой также является основным автором HTTP - протокола, который определяет передачу документов по всемирной паутине. HTTP - это протокол RESTful. Когда разработчики говорят об «использовании веб-служб REST», вероятно, правильнее будет сказать «с использованием HTTP».

SOAP - это протокол на основе XML, который туннелирует внутри HTTP-запроса / ответа, поэтому, даже если вы используете SOAP, вы также используете REST. Есть некоторые дебаты по поводу того, добавляет ли SOAP какие-либо существенные функциональные возможности к базовому HTTP.

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

Я думаю, что обоим есть свое место. Я считаю:

МЫЛО: лучший выбор для интеграции между устаревшими / критически важными системами и системой веб / веб-сервисов на базовом уровне, где WS- * имеет смысл (безопасность, политика и т. д.).

ОТДЫХ: лучший выбор для интеграции между веб-сайтами с общедоступным API в верхней части уровня (VIEW, т.е. javascripts, принимающие вызовы URI).

Краткое описание вопроса 2012 года:

Области, в которых REST действительно хорошо работает:

• Ограниченная пропускная способность и ресурсы. Помните, что структура возврата действительно в любом формате (определенном разработчиком). Кроме того, можно использовать любой браузер, потому что подход REST использует стандартные команды GET, PUT, POST и DELETE. Опять же, помните, что REST также может использовать объект XMLHttpRequest, который сегодня поддерживают большинство современных браузеров, что добавляет дополнительный бонус AJAX.

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

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

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

• Асинхронная обработка и вызов. Если вашему приложению требуется гарантированный уровень надежности и безопасности, то SOAP 1.2 предлагает дополнительные стандарты для обеспечения этого типа операций. Такие вещи, как WSRM - WS-Reliable Messaging.

• Официальные контракты. Если обе стороны (поставщик и потребитель) должны согласовать формат обмена, то SOAP 1.2 дает жесткие спецификации для этого типа взаимодействия.

• Операции с отслеживанием состояния. Если приложению требуется контекстная информация и управление диалоговым состоянием, тогда SOAP 1.2 имеет дополнительную спецификацию в структуре WS * для поддержки этих вещей (безопасность, транзакции, координация и т. д.). Для сравнения, подход REST заставит разработчиков построить эту нестандартную сантехнику.

http://www.infoq.com/articles/rest-soap-when-to-use-each

МЫЛО воплощает сервис-ориентированный подход к Web-сервисам, при котором методы (или глаголы) являются основным способом взаимодействия с сервисом. ОТДЫХ использует подход, ориентированный на ресурсы, в котором объект (или существительное) занимает центральное место.

В смысле с «PHP-вселенной» поддержка PHP любого продвинутого SOAP - отстой. Вы в конечном итоге будете использовать что-то вроде http://wso2.com/products/web-services-framework/php/, как только пересечете базовые потребности, даже если вы включите WS-Security или WS-RM без встроенной поддержки.

Создание SOAP-конверта, на мой взгляд, в PHP очень беспорядочно, способ создания пространств имен, xsd: nil, xsd: anytype и старые стилизованные Soap Services, которые используют кодирование SOAP (Бог знает, как это отличается) в сообщениях SOAP.

Избегайте всего этого беспорядка, придерживаясь REST, в REST нет ничего особенного, мы использовали его с самого начала WWW. Мы поняли, только когда вышел этот документ http://www.ics.uci.edu/~fielding/pubs/dissis/top.htm, он показывает, как мы можем использовать возможности HTTP для реализации служб RESTFul. HTTP по своей сути является REST, это не означает, что просто использование HTTP делает ваши службы RESTFul.

SOAP игнорирует основные возможности HTTP и рассматривает HTTP только как транспортный протокол, следовательно, теоретически он не зависит от транспортного протокола (на практике это не тот случай, когда вы слышали о заголовке SOAP Action? Если не погуглить сейчас!).

С ростом адаптации JSON и зрелости HTML5 с javascript REST с JSON стал наиболее распространенным способом работы с сервисами. Также была определена схема JSON, которую можно использовать для решений корпоративного уровня (все еще на ранних стадиях) вместе с WADL, если это необходимо.

Поддержка PHP для REST и JSON определенно лучше, чем существующая встроенная поддержка SOAP.

Добавляем сюда еще несколько слов BUZZ SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

кстати, мне очень нравится SOAP, особенно для спецификации WS-Security, это одна хорошая спецификация, и если кто-то, думающий об адаптации Enterprise JSON, определенно должен прийти с чем-то похожим на JSON, например, с шифрованием на уровне поля и т. д.

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

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

Тем не менее, SOAP действительно сияет, когда вы начинаете объединять несколько сервисов SOAP вместе как часть более крупного процесса, управляемого потоком данных (подумайте о корпоративном программном обеспечении). Это то, что многие примеры программирования SOAP не могут передать, потому что простая операция SOAP для выполнения чего-либо, например, получения цены акции, обычно слишком сложна для того, что она делает сама по себе, если она не представлена ​​в контексте предоставления машины. читаемый API с подробным описанием конкретных функций с заданными форматами данных для входов и выходов, который, в свою очередь, создается сценариями более крупного процесса.

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

Я смотрю на то же самое и думаю, это разные инструменты для разных проблем.

Стандартный протокол доступа к объектам (SOAP) - это язык XML, определяющий архитектуру сообщений и форматы сообщений, используемый веб-службами. Он содержит описание операций. WSDL - это язык на основе XML для описания веб-сервисов и способов доступа к ним. будет работать на SMTP, HTTP, FTP и т. д. Требуется поддержка промежуточного программного обеспечения, четко определенный механизм для определения сервисов, таких как WSDL + XSD, WS-Policy SOAP будет возвращать данные на основе XML. SOAP обеспечивает стандарты безопасности и надежности.

Веб-сервисы передачи репрезентативного состояния (RESTful). они представляют собой веб-службы второго поколения. Веб-службы RESTful обмениваются данными через HTTP, а не через службы на основе SOAP, и не требуют сообщений XML или определений API служб WSDL. для REST не требуется промежуточное ПО, требуется только поддержка HTTP. WADL Standard, REST может возвращать XML, простой текст, JSON, HTML и т. д.

Для многих типов клиентов проще использовать веб-службы RESTful, в то же время позволяя серверной стороне развиваться и масштабироваться. Клиенты могут использовать некоторые или все аспекты услуги и комбинировать ее с другими веб-службами.

1. REST использует стандартный HTTP, поэтому проще создавать клиентов и разрабатывать API.
2. REST допускает множество различных форматов данных, таких как XML, обычный текст, JSON, HTML, тогда как SOAP разрешает только XML.
3. REST имеет лучшую производительность и масштабируемость.
4. Отдых и может быть кэширован, а SOAP не может
5. Встроенная обработка ошибок там, где SOAP не имеет обработки ошибок
6. REST особенно полезен для КПК и других мобильных устройств.

REST - это сервисы, которые легко интегрировать с существующими веб-сайтами.

SOAP имеет набор протоколов, которые, помимо прочего, обеспечивают стандарты безопасности и надежности и взаимодействуют с другими клиентами и серверами, соответствующими WS. Веб-службы SOAP (такие как JAX-WS) полезны при обработке асинхронной обработки и вызова.

Для сложного API SOAP будет более полезным.

Один быстрый момент - протокол передачи и оркестровка;

Я использую протокол SOAP поверх TCP из соображений скорости, надежности и безопасности, включая согласование между машинами и сервисами (ESB) и внешними сервисами. Измените определение службы, оркестровка вызывает ошибку из-за изменения WSDL, это сразу становится очевидным и может быть перестроено / развернуто.

Не уверен, что вы можете сделать то же самое с REST - жду исправления или конечно! С помощью REST измените определение службы - об этом ничего не известно, пока оно не вернет 400 (или что-то еще).

Старый вопрос, но все еще актуален сегодня .... из-за того, что так много разработчиков в корпоративной сфере все еще используют его.

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

Понятно, что сейчас REST широко распространен и полезен, и в значительной степени является стандартом де-факто для Интернета, даже в Microsoft есть поддержка REST, включенная в Azure. Если бы мне нужно было полагаться на SOAP, я не мог бы делать то, что мне нужно, поскольку он слишком большой, громоздкий и раздражает небольшие встроенные устройства.

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

1. Из моего опыта. Я бы сказал, что REST дает вам возможность получить доступ к уже созданному URL-адресу. eg-> поиск слова в гугле. Этот URL-адрес можно использовать как веб-сервис для REST. В SOAP вы можете создать свою собственную веб-службу и получить к ней доступ через клиент SOAP.

2. REST поддерживает формат текста, JSON, XML. Следовательно, более универсален для связи между двумя приложениями. Хотя SOAP поддерживает только формат XML для передачи сообщений.

я создаю тест, чтобы найти, какие из них быстрее! я вижу такой результат:

на 1000 запросов:

• REST занял 3 секунды
• SOAP занял 7 секунд

на 10000 запросов:

• REST занял 33 секунды
• SOAP занял 69 секунд

на 1000000 запросов:

• REST занял 62 секунды
• SOAP занял 114 секунд