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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы рекомендовал вам сначала воспользоваться REST - если вы используете Java, посмотрите на JAX-RS и реализацию на Джерси . 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 с помощью веб-браузера.

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

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

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

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

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

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

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

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

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

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

О SOAP 1.2, преимуществах и недостатках по сравнению с "REST" ... Ну, с 2007 года вы можете описывать REST Web-сервисы с 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 2 в сравнениях.

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

• NEST-REST-SOAP : любой веб-сервис SOAP, который не может быть REST ... То есть «90%» из хорошо известных примеров SOAP.

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

МЫЛО в ОТДЫХНЫХ условиях

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

ПРОФИ

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

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

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

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

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

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

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

• Соответствие стандартам (25 голосов): как я сказал ранее @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: JSON не является стандартом IETF , но мы можем рассмотреть де-факто стандарт для сообщества веб-разработчиков.

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

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

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

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

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

• Требуется больше безопасности : когда требуется больше, чем HTTPS, и вам действительно нужны дополнительные функции для защиты, SOAP является лучшим выбором ( см. @Bell , 32 голоса). «Отправка сообщения по пути, более сложному, чем запрос / ответ, или по транспорту, который не использует HTTP», С. Сили . XML является основной проблемой, предлагая стандарты XML Encryption , XML Signature и канонизация 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 является тяжелым ... Итак, потребность в простых подходах требует выбора новой теоретической структуры ... И больших "игроков программного обеспечения для Web", таких как Google, Amazon, Yahoo и др. Выбрали лучшую альтернативу, то есть подход REST. Именно в этом контексте концепция REST стала «конкурирующей структурой», и сегодня (в 2012 году) эта альтернатива является стандартом де-факто для программистов.

устои

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

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

Это нюанс.

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

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

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

Стандарт 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 особенно полезен для КПК и других мобильных устройств.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С увеличением адаптации JSON и совершенствованием javascript в HTML5 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 поверх TCP по соображениям скорости, надежности и безопасности, в том числе для управления услугами между компьютерами (ESB) и внешними службами. При изменении определения службы оркестровка вызывает ошибку из-за изменения WSDL, и это сразу становится очевидным и может быть перестроено / развернуто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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