SOAP против REST (различия)

К сожалению, вокруг 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 на методы HTTP. Прочтите этот ответ для подробного объяснения этого.

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

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

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

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

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

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

Вопрос REST против SOAP - это не правильный вопрос.

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

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

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

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

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

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

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

Нестационарность

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

Cacheable.

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

Единый интерфейс

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

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

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

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

SOAP (Simple Object Access Protocol) и REST (Representation State Transfer) оба прекрасны по-своему. Поэтому я не буду их сравнивать. Вместо этого я пытаюсь обрисовать картину, когда я предпочитаю использовать REST, а когда SOAP.

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

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

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

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

Arin

или

"name": "Arin"

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

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

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

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

**Действительно! Как?

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

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

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

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

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

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

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

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

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

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

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

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

Отдых(репрезентационных овТейт Ттрансфер) Репрезентационных овТейт объекта Тметалл передан покой, т. е. мы не'т отправить объект, мы посылаем состояния объекта. REST-это архитектурный стиль. Он не определяет так много стандартов как мыло. Остальное для предоставления общедоступных API(например, API-интерфейс Facebook, API Карт Google) через интернет для обработки CRUD операций над данными. Отдых ориентирован на доступ к именованным ресурсам через единый унифицированный интерфейс.

Мыло(ЫРеа оbject адоступ рсогласно протоколу) Мыло приносит свой собственный протокол и фокусируется на выявлении части логики приложения (а не данные) в качестве услуг. Мыло раскрывает операции. Мыло ориентирована на доступ к названной операции, каждая операция реализации бизнес-логики. Хотя мыло обычно называют веб-сервисы это неправильно. Мыло имеет очень мало, если что-то делать с веб. Остальное обеспечивает истинную веб-сервисы на основе идентификаторов URI и HTTP.

Почему отдыхаем?

• С остальными использует стандартный http гораздо проще в Все путем.
• Остальным легче осуществить, требует меньшей пропускной способности и ресурсов.
• Остальное разрешает множество различных форматов данных, где в качестве мыла позволяет только XML.
• Остальное обеспечивает улучшенную поддержку клиентов браузера из-за его поддержка JSON.
• Остальное имеет лучшую производительность и масштабируемость. Остальное читает может быть кэширован, мыло на основе чтения не может быть кэширован.
• Если безопасность не является серьезной проблемой, и мы имеем ограниченные ресурсы. Или мы хотим создать API, который будет удобен для использования другими разработчиками публично, тогда мы должны идти с остальными.
• Если нужны операции CRUD без гражданства, а потом идти с остальными.
• Остальные обычно используется в социальных медиа, веб-чатов, мобильных сервисов и публичных API, как Google Карты.
• Спокойный возвращать различные MediaTypes для одного и того же ресурса, в зависимости от заголовка параметр запроса "не принимает" и как значение application/xml или приложение/JSON после и/пользователей/1234.формат JSONили сделать/user/1234.xml` для вам.
• Услуги отдыха предназначены, чтобы быть вызванным клиентское приложение, а не конечному пользователю напрямую.
• СТ в остальное приходит со овТейт Ттрансфер. Вы переводите государства вокруг вместо того, что сервера хранят его, это делает REST-сервисов масштабируемость.

Почему мыло?

• Мыло не очень проста в реализации и требует больше ресурсов.
• Запрос SOAP сообщение обрабатывается медленнее по сравнению с остальным, и он не использует механизм кэширования web.
• Только WS-безопасности: пока мыла поддерживает SSL (как и остальные) также поддерживает WS-безопасности, который добавляет некоторые корпоративные функции безопасности.
• Только WS-atomictransaction с: нужна кислота сделок за обслуживание, вам понадобится мыло.
• Только WS-ReliableMessaging: если ваше приложение требует асинхронной обработки и гарантированным уровнем надежности и безопасности. Остальное не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут сталкиваться с отказами связи с повтором.
• Если безопасность является главной заботой и ресурсы не ограничены, то мы должны использовать веб-служб SOAP. Как если мы создаем веб-сервис для платежных шлюзов, финансовых и телекоммуникационных связанных с работой, а потом мы уйдем с мылом, так как здесь нужна высокая безопасность.

файлы source1 файл source2

Разница между REST и SOAP

Мыло

1. SOAP-это протокол.
2. Мыло расшифровывается как простой протокол доступа к объектам.
3. Мыло может'т использовать остальные, потому что это протокол.
4. Мыло пользуется услугами интерфейсы предоставлять бизнес-логики.
5. Мыло определяет стандарты, которые должны быть строго соблюдены.
6. Мыло требует больше пропускной способности и ресурсов, чем остальные.
7. Мыло определяет свою собственную безопасность.
8. SOAP позволяет только формат данных XML.
9. Мыло является менее предпочтительным, чем остальные.

Отдых

1. REST-это архитектурный стиль.
2. Остальные стенды для передачи репрезентативного состояния.
3. Остальные могут использовать веб-служб SOAP, потому что это концепция, и можете использовать любой протокол, например HTTP, мыло.
4. Остальные использует URI, чтобы предоставлять бизнес-логику.
5. Остальных не определить слишком много стандартов как мыло.
6. Остальное требует меньшей пропускной способности и ресурсов, чем мыло.
7. Веб-служб RESTful наследует меры безопасности от базового транспорта.
8. Остальные разрешения разные форматы данных, такие как простой текст, HTML, XML и JSON и т. д.
9. Остальные более предпочтительным, чем мыло.

Для более подробной информации, пожалуйста, смотрите здесь

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

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

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

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

и gt; Во-первых: официально, правильный вопрос будет веб-сервисов на языке WSDL + мыло против отдых.

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

В практике, однако, никто не обращает внимания, так что давайте's слишком игнорировать

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

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

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

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

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

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

• `приложение myapp/читай-клиента и в теле сообщения, передать идентификатор клиента для чтения.
• `приложение myapp/обновление клиента и в теле, передать идентификатор клиента, а также новые данные
• `приложение myapp/удалить-клиента и идентификатор в организме

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

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

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

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

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

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

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

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

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