it-swarm-ru.tech

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

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

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

378
user13276

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

Аббревиатура "МЫЛО" - ложь. Он не прост, он не объектно-ориентирован, он не определяет никаких правил доступа. Это, возможно, протокол. Это худшая спецификация Дона Бокса за всю историю, и это настоящий подвиг, так как именно он совершил "СОМ".

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

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

560
mdhughes

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

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

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

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

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

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

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

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

197
Will Hartung

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

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

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

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

102
toluju

Краткий обзор 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

59
PmanAce

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

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

44
Mark Cidade

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

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

40
Dave Woldrich

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

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

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

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

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

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

Мне нужно идти дальше?

29
Josh M.

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

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

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

19
Travis Heseman

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

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

Лучший способ судить о спорах REST v SOAP - смотреть в Интернете - почти все крупные игроки в веб-пространстве: Google, Amazon, Ebay, Twitter и другие. использовать и отдавать предпочтение API-интерфейсам RESTful, а не SOAP.

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

17
James Strachan

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

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

16
gbjbaanb

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

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

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

15
irobson

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

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

13
John Saunders

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


Мыло, плюсы и минусы

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

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

  • SOAP-REST (= "REST-SOAP"): как показано Л.Манделем , WSDL2 может описывать REST webservice, и, если мы предположим, что приведенный в качестве примера 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 взаимно совместимы. REST, с другой стороны, не является стандартом W3C или ISO и не содержит нормативных сведений о периферии сервиса. Итак, как сказано ранее I , @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), в контексте, где НУЖНЫ СТАНДАРТЫ, вам нужно SOAP.

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

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

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

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

  • Соответствие стандартам (25 голосов): as I , @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0) сказал ранее, в контексте, где НУЖНЫ СТАНДАРТЫ, вам нужно SOAP.

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

МИНУСЫ

  • Структура SOAP более сложна (более 300 голосов): все ответы здесь и источники о "SOAP против 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 :

  • Потребность в стандартах и стабильных контрактах (см. Раздел "ПРОФИ"). PS: смотрите типичная "потребность в стандартах B2B", описанная @saille .

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

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

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

  • Требуется больше гибкости (меньше ограничений): SOAP не требуется точное соответствие с URI; не нужно ограничивать 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-х) эта альтернатива является де-факто стандартом для программистов.

Устои

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

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

10
Peter Krauss

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

10
Cruachan

Это нюанс.

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

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

9
cynicalman

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

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

Веб-сервисы Государственного Трансфера Представительства (RESTful). это веб-сервисы второго поколения. Веб-сервисы RESTful взаимодействуют через HTTP, а не с сервисами на основе SOAP и не требуют сообщений XML или определений API сервиса WSDL. для 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 особенно полезен PDA и ​​для других мобильных устройств.

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

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

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

9
kapil das

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

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

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

8
Chris Broski

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

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

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

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

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

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

7
Exitos

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

Мне интересно, что думают другие.

6
cranley

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

6
Mark Beckwith

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

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

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

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

6
Rick Sarvas

В смысле с "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/dis Диссертация/top.htm статья, показывающая, как мы можем использовать возможности HTTP для реализации RESTFul Services. HTTP изначально REST, это не значит, что использование HTTP делает ваши сервисы RESTFul.

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

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

4
shivaspk

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

4
Vibha Sanskrityayan

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

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

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

3
BlueChippy

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

2
neu242

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

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

  • Отдых занял 3 секунды
  • МЫЛО заняло 7 секунд

на 10 000 запросов:

  • Отдых занял 33 секунды
  • Мыло заняло 69 секунд

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

  • Отдых занял 62 секунды
  • SOAP заняло 114 секунд
2
Sonador

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

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

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

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

0
Remixed123

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

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