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

Акроним "SOAP" - ложь. Это не просто, он не Object-oriented, он не определяет правила доступа. Это, возможно, Протокол. Это худшая спецификация "Дон-бокс", и это настоящий подвиг, как он, человек, совершивший "СОМ".

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

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

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 моей жене.

Если у вас нет времени на его чтение, здесь короткая версия: REST - это немного смещение парадигмы, сосредоточившись на "существительных" и ограничивая количество "глаголов", которые вы можете применить к этим существительным. Единственными допустимыми глаголами являются "get", "put", "post" и "delete". Это отличается от SOAP, где многие разные глаголы могут применяться ко многим различным существительным (т.е. К множеству разных функций).

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

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

Быстрое решение вопроса 2012 года:

Области, в которых REST отлично работают, - это:

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

• Полностью безстоящие операции. Если операция должна быть продолжена, то REST не лучший подход, и SOAP может поместиться лучше. Однако, если вам нужны операции с отсутствием CRATE (создание, чтение, обновление и удаление), тогда 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нужно ли продолжать?

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

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

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

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

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

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

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

Я уверен, что Don Box создал SOAP в качестве шутки - "посмотрите, как вы можете вызывать RPC-методы через Интернет", и сегодня стонет, когда он понимает, каким раздутым кошмаром веб-стандартов он стал: -)

REST хорош, прост, реализован везде (так более "стандарт", чем стандарты) быстро и просто. Используйте REST.

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

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

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

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

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

Отвечая на вопрос, освещенный в 2012 году (по второму вопросу), и рассмотрим результаты сегодняшнего дня (другие ответы).

SOAP, за и против

О SOAP 1.2, преимуществах и недостатках при сравнении с "REST"... Ну, с 2007 года вы можете описать веб-службы REST с помощью WSDL, и используя протокол SOAP... То есть, если вы работаете немного сложнее, все стандарты W3C в стеке протоколов веб-сервисов могут REST!

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

• SOAP-REST (= "REST-SOAP" ): как показанный L.Mandel WSDL2 может описывать веб-службу REST, и, если мы предположим, что пример XML может быть окутан SOAP, вся реализация будет "SOAP-REST".

• NON-SOAP-REST: любая веб-служба REST, которая не может быть SOAP... То есть, "90%" хорошо знакомых примеров REST. Некоторые не используют XML (например, типичные AJAX REST используют JSON вместо), некоторые используют другие XML-структуры, без заголовков или правил SOAP. PS: чтобы избежать неформальности, мы можем предположить REST level 2 в сравнении.

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

• NON-REST-SOAP: любая веб-служба SOAP, которая не может быть REST... То есть "90%" хорошо знакомых примеров SOAP.

• NON-REST-NEITHER-SOAP: да, вселенная "моделирования веб-сервисов" включает в себя другие вещи (например, XML-RPC).

SOAP в условиях REST

Сравнение сопоставимых вещей: SOAP-REST с NON-SOAP-REST.

ПРОФИ

Объясняя некоторые термины,

• Договорная стабильность: для всех видов контрактов (как "письменные соглашения" ),

  • При использовании стандартов: все уровни W3C stack совместимы друг с другом. REST, с другой стороны, не является стандартом W3C или ISO и не имеет нормализованных данных об периферии обслуживания. Итак, как I, @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), упомянутых ранее, в контексте, где НУЖДЕН ДЛЯ СТАНДАРТОВ, вы нужен SOAP.

  • Используя лучшие практики: "подробный аспект" реализаций стека W3C, переводит соответствующие юридические/юридические/юридические соглашения.

• Надежность: безопасность структуры SOAP и заголовков. С метаданной коммуникацией (с полной выразительностью XML) и verification у вас есть "страховой полис" от любых изменений или шумов. SOAP имеет "надежность транзакций" (...) в отношении сбоев в связи. SOAP имеет больше возможностей для контроля логики повторения и, таким образом, может предоставлять дополнительные сквозные гарантии надежности и обслуживания ", E. Термана.

Сортировка профи по популярности,

• Лучшие инструменты (~ 70 голосов): SOAP в настоящее время имеет преимущество лучших инструментов, начиная с 2007 года и до 2012 года, потому что это хорошо определенный и широко распространенный стандарт. См. @MarkCidade (27 голосов), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

• Соответствие стандартам (25 голосов): I, @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), упомянутый ранее, в контексте, где НУЖДЕН ДЛЯ СТАНДАРТОВ, вам нужен SOAP.

• Надежность: страхование заголовков SOAP, @JohnSaunders (8 голосов).

CONS

• Структура SOAP более сложна (более 300 голосов): все ответы здесь и источники о SOAP vs REST проявляют некоторую степень неприязни к избыточности и сложности SOAP. Это является естественным следствием требований к формальной проверке (см. Ниже) и надежности (см. Выше). "REST NON-SOAP" (и XML-RPC, создатель SOAP) может быть более простым и неформальным.

• Ограничение "только XML" - это препятствие производительностипри использовании крошечных сервисов (~ 50 голосов): см. json.org/xml и этот вопрос, или этот другой. Этот момент проявляется @toluju (41) и другими.
  PS: as JSON не является стандартом IETF, но мы можем рассмотреть стандарт де-факто для сообщества веб-разработчиков.

Моделирование сервисов с помощью SOAP

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

• Необходимость стандартов и стабильных контрактов (см. раздел "PROS" ). PS: см. типичную "потребность в B2B для стандартов" , описанную @saille.

• Необходимость в инструментах (см. раздел "PROS" ). PS: стандарты и наличие формальных проверок (см. Ниже) являются важными проблемами для автоматизации инструментов.

• Параллельная интенсивная обработка (см. ниже раздел "Контекст/Основы" ): с большими и/или медленными процессами, независимо от сложности SOAP, надежность и стабильность - лучшие инвестиции.

• Требуется дополнительная защита: если требуется больше HTTPS, и вам действительно нужны дополнительные функции для защиты, SOAP - лучший выбор (см. @Bell, 32 голоса). "Отправка сообщения по пути, более сложному, чем запрос/ответ или транспорт, который не связан с HTTP ", S. Сили. XML является основной проблемой, предлагая стандарты для шифрования XML, подписи XML и канонизации XML, и только с помощью SOAP вы можете внедрить эти механизмы в сообщение по хорошо принятому стандарту WS-Security.

• Требуется больше гибкости (меньше ограничений): SOAP не нуждается в точном соответствии с URI; not nedd ограничивает HTTP; не нужно ограничивать до 4 глаголов. Как говорит @TravisHeseman (9 голосов), если вы хотите что-то "гибкое для произвольного количества клиентских технологий и использования", используйте SOAP. PS: помните, что XML более универсален/выразителен, чем JSON (и др.).

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

КОНТЕКСТ

Исторический

Для оценки тенденций необходима историческая перспектива. Для этого предмета перспектива 10 или 15 лет...

До стандартизации W3C существует некоторая анархия. Было сложно реализовать совместимые сервисы с различными структурами, а также более сложные, дорогостоящие и трудоемкие для реализации чего-то совместимого между компаниями. Стандарты стека W3C были легкими, севернее для взаимодействия наборов сложных веб-сервисов.

Для повседневных задач, таких как реализация AJAX, SOAP тяжелый... Итак, необходимость простых подходов должна избрать новую теорию-структуру... И большие "игроки веб-программного обеспечения", как Google, Amazon, Yahoo и др., Выбрали лучшую альтернативу, то есть подход REST. В этом контексте концепция REST появилась как "конкурирующая структура", и сегодня (2012 год) эта альтернатива - это de facto standard для программисты.

Основы

В контексте параллельных вычислений веб-службы предоставляют параллельные подзадачи; и протоколы, такие как SOAP, обеспечивают хорошую синхронизацию и связь. Не "любая задача": веб-сервисы можно классифицировать как грубый и неудобный parallelism.

По мере того как задача становится больше, она становится менее значимой "дискуссией по сложности" и становится более актуальной в отношении надежности сообщения и прочности контрактов.

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

Он нюансирован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Верхний "ответ" в этом потоке, похоже, говорит о том, что SOAP означает Simple Object-oriented Access Protocol, однако, глядя на wiki, O означает Object not Object-oriented. Это разные вещи.

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

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

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

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

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

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

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

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

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

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

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

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

С повышением адаптации 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, например, на шифрование на уровне поля и т.д.

SOAP воплощает сервисно-ориентированный подход к веб-сервисам - тот, в котором методы (или глаголы) являются основным способом взаимодействия с сервисом. REST использует ресурсо-ориентированный подход, в котором объект (или существительное) занимает центральное место.

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

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

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

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

для 1000 запросов:

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

для 10 000 запросов:

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

для 1 000 000 запросов:

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

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

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

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

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

Моя работа включает в себя разработку и разработку решений IoT (Internet of Things). К ним относится разработка кода для небольших встроенных устройств, которые взаимодействуют с облаком.

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

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