xml чайников - SOAP или REST для веб-служб?




разница vs (24)

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

Баунти-Edit:

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


Answers

Быстрая сдержанность на 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


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

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


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

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


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

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


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

SOAP, плюсы и минусы

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

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

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

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

Разумеется, для сравнения более концептуально сравните «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 совместимы друг с другом . REST, с другой стороны, не является стандартом W3C или ISO и не имеет нормализованных данных о периферийных устройствах службы. Итак, как I , @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), упомянутых ранее, в контексте, где НУЖДЕН ДЛЯ СТАНДАРТОВ, вам нужен SOAP.

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

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

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

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

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

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

МИНУСЫ

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

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

Услуги моделирования с помощью SOAP

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

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

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

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

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

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

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

КОНТЕКСТ

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

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

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

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

устои

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

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


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.


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

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

Это нюанс.

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

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


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

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

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

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

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

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


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


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

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

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

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


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

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

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

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


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

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

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


Я знаю, что это старый вопрос, но я должен опубликовать свой ответ - может быть, кто-то найдет его полезным. Я не могу поверить, сколько людей рекомендуют 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?

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


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


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

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

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

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


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


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

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

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

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

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

за 1 000 000 запросов:

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

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

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

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


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

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

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

SOAP игнорирует основные возможности HTTP и рассматривает HTTP так же, как транспортный протокол, следовательно, он является независимым от транспортного протокола в теории (на практике это не так, вы слышали о SOAP Action header? Если не 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) - язык 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, позволяя серверной стороне развиваться и масштабироваться. Клиенты могут выбрать использование некоторых или всех аспектов услуги и вытеснить ее с помощью других веб-сервисов.

  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) полезны при обработке асинхронной обработки и вызова.

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


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

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

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


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

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

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


Попробуйте поместить ваши данные в файл, скажем, body.json а затем используйте

curl -H "Content-Type: application/json" --data @body.json http://localhost:8080/ui/webapp/conf




xml web-services rest soap