SOAP vs REST (различия)

Ответ 1

К сожалению, в REST существует много дезинформации и неправильных представлений. Не только ваш вопрос и ответ @cmd отражают их, но большинство вопросов и ответов, связанных с предметом в Stack Overflow.

SOAP и REST нельзя сравнивать напрямую, так как первый - это протокол (или, по крайней мере, пытается быть), а второй - архитектурный. Вероятно, это один из источников беспорядка вокруг него, поскольку люди обычно называют REST любым HTTP-API, который не является SOAP.

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

Клиент REST больше похож на браузер. Это общий клиент, который знает, как использовать протокол и стандартизованные методы, и приложение должно соответствовать этому. Вы не нарушаете стандарты протокола, создавая дополнительные методы, вы используете стандартные методы и создаете с ними действия по типу вашего медиа. Если все сделано правильно, там меньше связей, и изменения могут быть обработаны более изящно. Предполагается, что клиент должен войти в службу REST с нулевым знанием API, за исключением точки входа и типа носителя. В SOAP клиенту нужны предыдущие знания обо всем, что он будет использовать, или он даже не начнет взаимодействие. Кроме того, клиент REST может быть расширен кодом по требованию, предоставленным самим сервером, классическим примером является код JavaScript, используемый для управления взаимодействием с другой службой на стороне клиента.

Я думаю, что это решающие моменты, чтобы понять, что такое REST, и как он отличается от SOAP:

• REST не зависит от протокола. Он не связан с HTTP. В значительной степени, как вы можете следить за ftp-ссылкой на веб-сайте, приложение REST может использовать любой протокол, для которого существует стандартизованная схема URI.

• REST не является отображением методов CRUD to HTTP. Прочтите этот ответ для подробного объяснения этого.

• REST стандартизирован как части, которые вы используете. Безопасность и аутентификация в HTTP стандартизованы, так что вы используете при выполнении REST через HTTP.

• REST не является REST без гипермедиа и HATEOAS. Это означает, что клиент знает только URI точки входа, и ресурсы должны возвращать ссылки, которым должен следовать клиент. Эти причудливые генераторы документации, которые предоставляют шаблоны URI для всего, что вы можете сделать в REST API, полностью упускают из виду. Они не только документируют то, что должно соответствовать стандарту, но когда вы это делаете, вы связываете клиента с одним конкретным моментом в эволюции API, и любые изменения в API должны быть документированы и применены, или он сломается.

• REST - это архитектурный стиль самого веб-сайта. Когда вы вводите Stack Overflow, вы знаете, что такое Пользователь, вопрос и ответ, вы знаете типы медиа, и веб-сайт предоставляет вам ссылки на них. API REST должен сделать то же самое. Если мы разработали Интернет так, как люди должны думать, что REST должен быть сделан, вместо того, чтобы иметь домашнюю страницу со ссылками на вопросы и ответы, у нас была бы статическая документация, объясняющая, что для просмотра вопроса вам нужно взять URI stackoverflow.com/questions/<id>, замените id на Question.id и вставьте его в свой браузер. Это глупость, но то, что многие считают REST.

Эта последняя точка не может быть подчеркнута достаточно. Если ваши клиенты строят URI из шаблонов в документации и не получают ссылок в представлениях ресурсов, это не REST. Рой Филдинг, автор REST, дал понять это сообщение в блоге: API REST должен быть основан на гипертексте.

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

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

Ответ 2

REST vs SOAP не правильный вопрос.

REST, в отличие от SOAP - это протокол не.

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

REST понятия называются ресурсами. Представление ресурса должно быть неактивным. Он представлен через некоторый тип медиа. Некоторые примеры типов медиа включают XML, JSON и RDF. Ресурсы обрабатываются компонентами. Компоненты запрашивают и управляют ресурсами через стандартный унифицированный интерфейс. В случае HTTP этот интерфейс состоит из стандартных HTTP-операций, например. GET, PUT, POST, DELETE.

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

Основные принципы REST

Коммуникация клиент-сервер

Архитектуры клиент-сервер имеют очень четкое разделение проблем. Все приложения, созданные в стиле RESTful, также должны быть клиент-сервером в принципе.

Stateless

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

Cacheable

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

Равномерный интерфейс

Все компоненты должны взаимодействовать через единый унифицированный интерфейс. Поскольку взаимодействие всех компонентов происходит через этот интерфейс, взаимодействие с различными службами очень простое. Интерфейс тот же! Это также означает, что изменения в реализации могут быть сделаны изолированно. Такие изменения не повлияют на взаимодействие фундаментальных компонентов, поскольку равномерный интерфейс всегда остается неизменным. Один из недостатков заключается в том, что вы застряли в интерфейсе. Если оптимизация может быть предоставлена ​​конкретной службе, изменив интерфейс, вам не повезло, поскольку REST запрещает это. Однако с яркой стороны REST оптимизирован для Интернета, поэтому невероятная популярность REST по HTTP!

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

Смотрите этот блог post в Принципы дизайна REST для более подробной информации о REST и указанные выше пули.

EDIT: обновить контент на основе комментариев

Ответ 3

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

Что такое полезная нагрузка?

Когда данные отправляются через Интернет, каждая передаваемая единица включает в себя как информацию заголовка, так и фактические отправляемые данные. Заголовок идентифицирует источник и назначение пакета, в то время как фактические данные упоминаются как полезная нагрузка. В общем, полезная нагрузка - это данные, которые передаются от имени приложения, и данные, полученные системой назначения.

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

Так скажите мне среди упомянутых ниже двух этих сообщений, какое из них дешевле отправить?

<name>Arin</name>

или же

"name": "Arin"

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

Поэтому я пытаюсь сказать, что отправка данных по сети в формате JSON дешевле, чем отправка данных в формате XML для полезной нагрузки.

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

Теперь SOAP поддерживает только XML, но также имеет свои преимущества.

В самом деле! Как?

SOAP опирается на XML тремя способами. Конверт - определяет, что находится в сообщении и как его обрабатывать.

Набор правил кодирования для типов данных и, наконец, компоновка вызовов процедур и собранных ответов.

Этот конверт отправляется через транспорт (HTTP/HTTPS), и выполняется RPC (удаленный вызов процедуры), а конверт возвращается с информацией в формате документа XML.

Важным моментом является то, что одним из преимуществ SOAP является использование "общего" транспорта, но REST использует HTTP/HTTPS. SOAP может использовать практически любой транспорт для отправки запроса, но REST не может. Таким образом, здесь мы получили преимущество использования SOAP.

Как я уже упоминал в предыдущем параграфе "REST использует HTTP/HTTPS", давайте углубимся в эти слова.

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

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

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

Но SOAP имеет всестороннюю поддержку как управления транзакциями на основе ACID для краткосрочных транзакций, так и управления транзакциями на основе компенсации для длительных транзакций. Он также поддерживает двухфазную фиксацию через распределенные ресурсы.

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

Вот "Учебник по Java EE 6", в котором говорится, что дизайн RESTful может быть подходящим, когда выполняются следующие условия. Посмотри.

Надеюсь, вам понравилось читать мой ответ.

Ответ 4

REST (RE презентационного S татэ T ransfer)
RE презентационного S Тейта объекта Т ransferred является REST т.е. мы не посылаем объект, мы отправляем состояние объекта. ОТДЫХ - это архитектурный стиль. Он не определяет так много стандартов, как SOAP. REST предназначен для демонстрации общедоступных API (например, API Facebook, API Карт Google) через Интернет для обработки операций CRUD с данными. REST ориентирован на доступ к именованным ресурсам через единый согласованный интерфейс.

SOAP (S реали O ▪ Таблица Д оступ Р rotocol)
SOAP предоставляет свой собственный протокол и фокусируется на представлении частей логики приложения (не данных) как сервисов. SOAP выставляет операции. SOAP ориентирован на доступ к именованным операциям, каждая операция реализует некоторую бизнес-логику. Хотя SOAP обычно называют веб-сервисами, это неправильно. SOAP имеет очень мало общего с Интернетом. REST предоставляет настоящие веб-сервисы на основе URI и HTTP.

Почему ОТДЫХ?

• Поскольку REST использует стандартный HTTP, он намного проще практически всегда.
• REST проще в реализации, требует меньше пропускной способности и ресурсов.
• REST допускает множество различных форматов данных, тогда как SOAP разрешает только XML.
• REST позволяет улучшить поддержку клиентов браузера благодаря поддержке JSON.
• REST имеет лучшую производительность и масштабируемость. Чтения REST могут быть кэшированы, чтения на основе SOAP не могут быть кэшированы.
• Если безопасность не является серьезной проблемой, и у нас ограниченные ресурсы. Или мы хотим создать API, который будет легко использоваться другими разработчиками публично, тогда мы должны перейти к REST.
• Если нам нужны CRUD-операции без сохранения состояния, используйте REST.
• REST обычно используется в социальных сетях, веб-чате, мобильных сервисах и публичных API, таких как Google Maps.
• Служба RESTful возвращает различные MediaTypes для одного и того же ресурса, в зависимости от параметра заголовка запроса "Accept" в качестве application/xml или application/json для POST и /user/1234.json или GET /user/1234.xml для GET.
• Службы REST предназначены для вызова клиентским приложением, а не конечным пользователем напрямую.
• ST в покое происходит от S татэ T ransfer. Вы передаете состояние вместо того, чтобы сервер сохранял его, это делает службы REST масштабируемыми.

Почему мыло?

• SOAP не очень прост в реализации и требует большей пропускной способности и ресурсов.
• Запрос сообщения SOAP обрабатывается медленнее по сравнению с REST и не использует механизм веб-кэширования.
• WS-Security: хотя SOAP поддерживает SSL (как и REST), он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия.
• WS-AtomicTransaction: нужны транзакции ACID через сервис, вам понадобится SOAP.
• WS-ReliableMessaging: если вашему приложению требуется асинхронная обработка и гарантированный уровень надежности и безопасности. Rest не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут иметь дело с сбоями связи при повторных попытках.
• Если безопасность является серьезной проблемой и ресурсы не ограничены, тогда мы должны использовать веб-сервисы SOAP. Например, если мы создаем веб-сервис для платежных шлюзов, финансовой и телекоммуникационной работы, то мы должны использовать SOAP, поскольку здесь требуется высокий уровень безопасности.

source1
source2

Ответ 5

SOAP и веб-службы REST

Существует много различий между веб-службами SOAP и REST. Ниже приведены важные 10 различий между SOAP и REST:

• SOAP - это протокол . REST - это архитектурный стиль.
• SOAP означает Простой протокол доступа к объектам. REST означает REpresentational State Transfer.
• SOAP не может использовать REST, потому что это протокол. REST может использовать веб-службы SOAP, потому что это концепция и может использовать любой протокол, такой как HTTP, SOAP.
• SOAP использует интерфейсы служб для раскрытия бизнес-логики. REST использует URI для раскрытия бизнес-логики.
• В Java JAX-WS используется Java-API для веб-сервисов SOAP. В Java JAX-RS - это API-интерфейс java для веб-служб RESTful.
• SOAP определяет стандарты, строго соблюдаемые. REST не определяет слишком много стандартов, таких как SOAP.
• SOAP требует больше полосы пропускания и ресурса, чем REST. REST требует меньше полосы пропускания и ресурса, чем SOAP.
• SOAP определяет собственную безопасность. Веб-службы RESTful наследуют меры безопасности от основного транспорта.
• SOAP разрешает только формат данных XML. REST позволяет использовать другой формат данных, например, обычный текст, HTML, XML, JSON и т.д.
• SOAP менее предпочтительный, чем REST. REST более предпочтительный, чем SOAP.

Ответ 6

Разница между отдыхом и мылом

SOAP

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

REST

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

Подробнее см. здесь

Ответ 7

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

Основы REST

• Все в REST рассматривается как ресурс.
• Каждый ресурс идентифицируется с помощью URI.
• Использует единые интерфейсы. Ресурсы обрабатываются с помощью операций POST, GET, PUT, DELETE, которые похожи на операции Create, Read, update и Delete (CRUD).
• Будьте без гражданства. Каждый запрос является независимым запросом. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса.
• Коммуникации выполняются через представления. Например. XML, веб-службы JSON RESTful Веб-службы RESTFul основаны на методах HTTP и концепции REST. Веб-служба RESTFul обычно определяет базовый URI для сервисов, поддерживаемые MIME-типы (XML, текст, JSON, определяемые пользователем,...) и набор операций (POST, GET, PUT, DELETE), которые поддерживаются.

Основы SOAP

• WSDL определяет контракт между клиентом и сервисом и статичен по своей природе.
• SOAP создает протокол на основе XML поверх HTTP или иногда TCP/IP.
• SOAP описывает функции и типы данных.
• SOAP является преемником XML-RPC и очень похож, но описывает стандартный способ связи.
• Несколько языков программирования имеют встроенную поддержку SOAP, вы обычно загружаете URL-адрес веб-службы, и вы можете вызывать его функции веб-службы без необходимости использования определенного кода.
• Двоичные данные, которые отправляются, должны сначала кодироваться в формат, такой как base64.
• Имеет несколько протоколов и технологий, связанных с ним: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

Одним из основных преимуществ SOAP является то, что у вас есть описание службы WSDL. Вы можете в значительной степени обнаружить службу автоматически и создать полезный клиентский прокси из этого описания службы (сгенерировать вызовы служб, необходимые типы данных для методов и т.д.). Обратите внимание, что с версией 2.0 WSDL поддерживает все HTTP-глаголы и может использоваться для документирования служб RESTful, но для этой цели существует менее подробный вариант в WADL (Language Description Language).

С помощью служб RESTful безопасность сообщений обеспечивается транспортным протоколом (HTTPS) и только точка-точка. Он не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут реагировать на сбои в связи путем повторной попытки. SOAP имеет успешную/повторную логику и обеспечивает сквозную надежность даже через посредников SOAP.

Одним из основных преимуществ API RESTful является гибкость представления данных, например, вы можете сериализовать свои данные в формате XML или JSON. API RESTful более чисты или понятны, потому что они добавляют элемент использования стандартизованных URI и придают большое значение используемому глаголу HTTP (т.е. GET, POST, PUT и DELETE).

RESTful-сервисы также легки, то есть у них нет много дополнительной разметки xml. Чтобы вызывать RESTful API все, что вам нужно, это браузер или HTTP-стек, и почти все устройства или машины, подключенные к сети, имеют это.

Преимущества REST

• Так как REST использует стандартный HTTP, он намного проще в любой момент. Создание клиентов, разработка API-интерфейсов, документация намного легче понять, и существует очень много вещей, которые REST не делает проще/лучше, чем SOAP.
• REST позволяет использовать много разных форматов данных, где SOAP разрешает только XML. Хотя это может показаться, что это добавляет сложности для REST, потому что вам нужно обрабатывать несколько форматов, по моему опыту это действительно было очень полезно. JSON обычно лучше подходит для данных и анализирует гораздо быстрее. REST позволяет улучшить поддержку браузеров благодаря поддержке JSON.
• REST имеет лучшую производительность и масштабируемость. Чтение REST может быть кэшировано, чтение на основе SOAP не может быть кэшировано.
• Никакие дорогие инструменты не требуют взаимодействия с веб-службой.
• Меньшая кривая обучения
• Эффективный (SOAP использует XML для всех сообщений, REST может использовать более мелкие форматы сообщений)
• Быстрый (не требуется большая обработка)
• Ближе к другим веб-технологиям в философии дизайна

Преимущества SOAP

• WS-Security: Пока SOAP поддерживает SSL (как и REST), он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия. Поддерживает идентификацию через посредников, а не только точку (SSL). Он также обеспечивает стандартную реализацию целостности данных и конфиденциальности данных. Вызов "Enterprise" не означает, что он более безопасен, он просто поддерживает некоторые средства безопасности, которые типичные интернет-сервисы не нужны, на самом деле они действительно нужны только в нескольких сценариях "предприятия".
• WS-AtomicTransaction: Требуется ACID Transactions над сервисом, вам понадобится SOAP. Хотя REST поддерживает транзакции, он не является исчерпывающим и не совместим с ACID. К счастью, транзакции ACID почти никогда не имеют смысла в Интернете. REST ограничивается самим HTTP, который не может обеспечить двухфазное принятие через распределенные транзакционные ресурсы, но SOAP может. Интернет-приложениям обычно не нужен этот уровень надежности транзакций, иногда делаются корпоративные приложения.
• WS-ReliableMessaging: У Rest нет стандартной системы обмена сообщениями и ожидает, что клиенты будут реагировать на сбои в связи путем повторной попытки. SOAP имеет успешную/повторную логику и обеспечивает сквозную надежность даже через посредников SOAP.
• Язык, платформа и транспорт независимы (REST требует использования HTTP)
• Хорошо работает в распределенных корпоративных средах (REST предполагает прямую связь "точка-точка" ).
• Унифицированная
• Обеспечивает значительную расширяемость до сборки в виде стандартов WS
• Встроенная обработка ошибок
• Автоматизация при использовании с некоторыми языковыми продуктами

Где использовать REST

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

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

Где использовать SOAP

где SOAP работает как отличное решение:

• Асинхронная обработка и вызов:, если ваше приложение нуждается в гарантированном уровне надежности и безопасности, тогда SOAP 1.2 предлагает дополнительные стандарты для обеспечения такого типа операций. Такие вещи, как WSRM - WS-Reliable Messaging.
• Формальные контракты:, если обе стороны (поставщик и потребитель) должны согласовать формат обмена, тогда SOAP 1.2 дает жесткие спецификации для такого типа взаимодействия.
• Операции с состоянием:, если для приложения требуется контекстная информация и управление диалоговым состоянием, тогда SOAP 1.2 имеет дополнительную спецификацию в структуре WS для поддержки этих вещей (безопасность, транзакции, координация и т.д.). Сравнительно, подход REST заставил бы разработчиков создавать эту обычную сантехнику.

Ответ 8

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

Ответ 9

ИМХО, вы не можете сравнивать SOAP и REST, где это две разные вещи.

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

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

REST представляет состояние (как ресурсы) сервера с URL-адреса. Он не имеет состояния и клиенты не должны иметь предварительные знания для взаимодействия с сервером, кроме понимания гипермедиа.

Ответ 10

  Прежде всего: официально, правильный вопрос будет web services + WSDL + SOAP против REST.

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

На практике, однако, все это игнорируют, так что пусть это тоже игнорируется

Уже есть технические ответы, поэтому я постараюсь дать некоторую интуицию.

Допустим, вы хотите вызвать функцию на удаленном компьютере, реализованную на каком-то другом языке программирования (это часто называют удаленным вызовом процедуры /RPC). Предположим, что функцию можно найти по определенному URL, предоставленному человеком, который ее написал. Вы должны (как-то) отправить ему сообщение и получить ответ. Итак, нужно рассмотреть два основных вопроса.

• какой формат сообщения вы должны отправить
• как переносить сообщение туда и обратно

По первому вопросу официальное определение - WSDL. Это файл XML, который в подробном и строгом виде описывает, какие параметры, каковы их типы, имена, значения по умолчанию, имя вызываемой функции и т.д. Пример WSDL здесь показывает, что файл читается человеком (но не легко).

На второй вопрос есть разные ответы. Однако на практике используется только SOAP. Его основная идея: обернуть предыдущий XML (фактическое сообщение) в еще один XML (содержащий информацию о кодировке и другие полезные вещи) и отправить его по HTTP. Метод POST HTTP используется для отправки сообщения, так как всегда есть тело.

Основная идея всего этого подхода заключается в том, что вы сопоставляете URL-адрес с функцией, то есть с действием. Итак, если у вас есть список клиентов на каком-либо сервере, и вы хотите просмотреть/обновить/удалить его, у вас должно быть 3 URL:

• myapp/read-customer и в теле сообщения передайте идентификатор клиента для чтения.
• myapp/update-customer и в теле, передайте идентификатор клиента, а также новые данные
• myapp/delete-customer и идентификатор в теле

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

Так, с подходом REST, клиент номер 12 будет найден в URL myapp/customers/12. Чтобы просмотреть данные клиента, вы нажимаете URL-адрес с помощью запроса GET. Чтобы удалить его, тот же URL, с глаголом DELETE. Чтобы обновить его, снова , тот же URL-адрес с глаголом POST и новое содержимое в теле запроса.

Подробнее о требованиях, которым должен соответствовать сервис, чтобы он считался действительно RESTful, см. в модели зрелости Ричардсона. В статье приводятся примеры и, что более важно, объясняется, почему (так называемая) служба SOAP является службой REST уровня 0 (хотя уровень 0 означает низкое соответствие этой модели, это не оскорбительно и все еще полезно во многих случаях).

Ответ 11

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

Ответ 12

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

Что такое веб-служба REST

Аббревиатура REST означает передачу State State State Transfer, это означает, что каждый уникальный URL-адрес является представлением некоторого объекта. Вы можете получить содержимое этого объекта с помощью HTTP GET, чтобы удалить его, затем вы можете использовать POST, PUT или DELETE для изменения объекта (на практике большинство служб используют POST для этого).

Кто использует REST?

Все веб-службы Yahoo используют REST, в том числе API Flickr, del.icio.us, pubsub, bloglines, technorati, и eBay, и Amazon имеют веб-службы для REST и SOAP.

Кто использует SOAP?

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

REST vs SOAP

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

Основные преимущества веб-служб REST:

• Легкий - не много дополнительной разметки xml
• Результаты, доступные для чтения.
• Простота сборки - не требуется никаких инструментов.

SOAP также имеет некоторые преимущества:

• Легко потреблять - иногда
• Проверка жесткого типа, соблюдение контракта
• Средства разработки

Для использования веб-сервисов иногда бывает, что между ними это проще. Например, веб-сервис Google AdWords действительно сложно потреблять (в любом случае в CF), он использует заголовки SOAP и ряд других вещей, которые делают его довольно сложным. С другой стороны, веб-служба Amazon REST иногда может быть сложной для синтаксического анализа, поскольку она может быть сильно вложенной, а схема результата может варьироваться в зависимости от того, что вы ищете.

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

Надеюсь, это поможет вам:)

Ответ 13

Дополнение для:

++ Ошибка, возникающая при приближении к REST, заключается в том, чтобы думать о ней как о "веб-сервисах с URL-адресами" - думать о REST как о другом способе удаленного вызова процедур (RPC), например SOAP, но вызывается через простые URL-адреса HTTP и без SOAP больших пространств имен XML.

++ Напротив, REST имеет мало общего с RPC. В то время как RPC ориентирован на обслуживание и ориентирован на действия и глаголы, REST ориентирован на ресурсы, подчеркивая вещи и существительные, составляющие приложение.

Ответ 14

Многие из этих ответов совершенно забыли упомянуть средства управления гипермедиа (HATEOAS), которые являются фундаментальными для REST. Несколько других коснулись этого, но не очень хорошо объяснили это.

Эта статья должна объяснить разницу между концепциями, не затрагивая некоторые особенности SOAP.

Ответ 15

Мыло

• SOAP означает протокол простого доступа к объектам

• SOAP - это протокол связи приложений

• SOAP - это формат для отправки и получения сообщений

• SOAP не зависит от платформы

• SOAP основан на XML

• SOAP - рекомендация W3C

Почему SOAP?

• Для веб-приложений важно иметь возможность общаться через Интернет.

• Лучший способ общения между приложениями - HTTP, потому что HTTP поддерживается всеми браузерами и серверами Интернета. Для этого был создан SOAP.

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

API REST

• Передача репрезентативного состояния. В нем описывается, как одна система может связывать состояние с другим. Одним из примеров может быть состояние продукта (его имя, описание и т.д.), Представленное как XML, JSON или обычный текст. Обобщенная идея состояния называется ресурсом.

SOAP Vs. REST

Ответ 16

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

источник

источник

Подробнее здесь