SOAP или REST для веб-служб?
Является ли REST лучшим подходом к работе с веб-сервисами или SOAP? Или это разные инструменты для разных задач? Или это нюанс, то есть один лучше на определенных аренах, чем другой, и т. Д.?
Баунти-Edit:
Теперь, почти три года спустя, я хотел бы снова задать этот вопрос - предложить щедрость, чтобы поощрить всесторонний ответ. Я был бы особенно признателен за информацию об этих концепциях и их связи с PHP-вселенной, а также с современными высокопроизводительными веб-приложениями.
28 ответов
Я создал один из первых серверов 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 заставил бы разработчиков создавать эту нестандартную систему.
В настоящее время 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 для отправки внеполосных данных типа "заголовок"?)
Ответ на обновленный (по второй награде) вопрос за 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 переводит соответствующие человеческие / юридические / юридические соглашения.
Надежность: безопасность структуры и заголовков 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, подписи 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 является тяжелым... Итак, потребность в простых подходах требует выбора новой теоретической структуры... И больших "игроков программного обеспечения для Web", таких как Google, Amazon, Yahoo и др. Выбрали лучшую альтернативу, то есть подход REST. Именно в этом контексте концепция REST стала "конкурирующей структурой", и сегодня (в 2012 году) эта альтернатива является стандартом де-факто для программистов.
устои
В контексте параллельных вычислений веб-сервисы предоставляют параллельные подзадачи; и протоколы, такие как SOAP, обеспечивают хорошую синхронизацию и связь. Не "любая задача": веб-сервисы можно классифицировать как
грубый и неловкий параллелизм.
По мере того, как задача становится больше, она становится менее значимой "дискуссией о сложности" и становится все более актуальной: надежность коммуникации и надежность контрактов.
Не забывайте XML-RPC. Если вы ищете легковесное решение, то многое можно сказать о протоколе, который может быть определен на нескольких страницах текста и реализован в минимальном объеме кода. XML-RPC существует уже много лет, но какое-то время вышел из моды - но минималистская привлекательность, похоже, в последнее время оживляет его.
Я смотрю на то же самое, и я думаю, что это разные инструменты для разных задач.
Стандарт 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, позволяя серверной стороне развиваться и масштабироваться. Клиенты могут выбрать использование некоторых или всех аспектов службы и объединить ее с другими веб-службами.
- REST использует стандартный HTTP, поэтому проще создавать клиентов, разрабатывать API
- REST допускает множество различных форматов данных, таких как XML, простой текст, JSON, HTML, а SOAP разрешает только XML.
- REST имеет лучшую производительность и масштабируемость.
- Отдых и может быть кэшировано, а SOAP не может
- Встроенная обработка ошибок, где SOAP не имеет обработки ошибок
- REST особенно полезен для КПК и других мобильных устройств.
REST - это сервисы, которые легко интегрировать с существующими сайтами.
SOAP имеет набор протоколов, которые, помимо прочего, обеспечивают стандарты безопасности и надежности и взаимодействуют с другими клиентами и серверами, соответствующими требованиям WS. Веб-службы SOAP (такие как JAX-WS) полезны при обработке асинхронной обработки и вызова.
Для сложных API SOAP будет более полезным.
Это нюанс.
Если вам нужно, чтобы ваши сервисы взаимодействовали с другими системами, многие клиенты будут более довольны SOAP из-за уровней "проверки", которые вы выполняете с контрактами, WSDL и стандартом SOAP.
Для повседневных систем, обращающихся к системам, я думаю, что SOAP - это много ненужных накладных расходов, когда подойдет простой вызов HTML.
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. Если вы хотите передавать структурированные данные между внутренними сервисами, используйте SOAP.
Иногда SOAP может быть очень неудобной для настройки, и это часто излишне для простого обмена данными между веб-клиентом и сервером. К сожалению, самые простые примеры программирования, которые я видел (и усвоил), несколько усиливают это восприятие.
Тем не менее, SOAP действительно сияет, когда вы начинаете объединять несколько сервисов SOAP вместе в рамках более крупного процесса, управляемого рабочим потоком данных (например, корпоративное программное обеспечение). Это то, что многие из примеров программирования SOAP не в состоянии передать, потому что простая операция SOAP, чтобы сделать что-то, например, получить цену акции, как правило, слишком усложняется тем, что она делает сама, если она не представлена в контексте предоставления машины удобочитаемый API, детализирующий конкретные функции с заданными форматами данных для входов и выходов, которые, в свою очередь, записываются в сценарии более крупного процесса.
Это, в некотором смысле, печально, так как на самом деле 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/dissertation/top.htm Диссертация/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, например, шифрование на уровне поля и т. д.
SOAP воплощает сервис-ориентированный подход к веб-сервисам, в котором методы (или глаголы) являются основным способом взаимодействия с сервисом. REST использует ресурсно-ориентированный подход, при котором объект (или существительное) занимает центральное место.
Один быстрый момент - протокол передачи и оркестровка;
Я использую SOAP поверх TCP по соображениям скорости, надежности и безопасности, в том числе для управления услугами между компьютерами (ESB) и внешними службами. При изменении определения службы оркестровка вызывает ошибку из-за изменения WSDL, и она сразу становится очевидной и может быть перестроена / развернута.
Не уверен, что вы можете сделать то же самое с REST - я жду исправления или курса! С REST измените определение сервиса - ничего не будет известно об этом, пока он не вернет 400 (или что-то еще).
Я создаю ориентир, чтобы найти, какие из них быстрее! я вижу этот результат:
на 1000 запросов:
- Отдых занял 3 секунды
- Мыло заняло 7 секунд
на 10 000 запросов:
- Отдых занял 33 секунды
- Мыло заняло 69 секунд
для 1 000 000 запросов:
- Отдых занял 62 секунды
- Мыло заняло 114 секунд
Если вы ищете совместимость между различными системами и языками, я бы определенно пошел на REST. У меня было много проблем, пытаясь заставить SOAP работать между.NET и Java, например.
1. Из моего опыта. Я бы сказал, что REST дает вам возможность получить доступ к уже созданному URL. например-> поиск слова в гугле. Этот URL может быть использован как веб-сервис для REST. В SOAP вы можете создать свой собственный веб-сервис и получить к нему доступ через клиент SOAP.
- REST поддерживает текст, формат JSON,XML. Следовательно, более универсальный для связи между двумя приложениями. Пока SOAP поддерживает только формат XML для обмена сообщениями.
Старый вопрос, но все еще актуальный сегодня.... из-за того, что многие разработчики в корпоративном пространстве все еще используют его.
Моя работа включает в себя проектирование и разработку решений IoT (Internet of Things). В том числе разработка кода для небольших встроенных устройств, которые взаимодействуют с облаком.
Ясно, что REST теперь широко принят и полезен, и в значительной степени является стандартом defacto для Интернета, даже у Microsoft есть поддержка REST, включенная в Azure. Если бы мне нужно было полагаться на SOAP, я не мог бы делать то, что мне нужно, потому что он слишком большой, громоздкий и раздражающий для небольших встроенных устройств.
ОТДЫХ простой, чистый и маленький. Это делает его идеальным для небольших встроенных устройств. Я всегда кричу, когда работаю с веб-разработчиком, который отправляет мне WSDL. Поскольку мне придется начать образовательную кампанию о том, почему это просто не сработает, и почему им придется изучать REST.