Простое объяснение SOAP и REST

SOAP - "Простой протокол доступа к объектам"

SOAP - это метод передачи сообщений или небольших объемов информации через Интернет. Сообщения SOAP форматируются в XML и обычно отправляются с использованием HTTP (протокола передачи гипертекста).

Остальное - переход в репрезентативное состояние

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

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

Протокол простого доступа к объектам (SOAP):

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

Передача репрезентативного состояния (REST):

• REST не обязательно должен быть поверх HTTP, но большинство моих замечаний ниже будут иметь предвзятость HTTP.
• REST очень легкий, он говорит, подождите минутку, нам не нужна вся эта сложность, созданная SOAP.
• Обычно использует обычные методы HTTP вместо большого формата XML, описывающего все. Например, для получения ресурса вы используете HTTP GET, чтобы разместить ресурс на сервере, вы используете HTTP PUT. Чтобы удалить ресурс на сервере, вы используете HTTP DELETE.
• REST очень прост в том, что он использует методы HTTP GET, POST и PUT для обновления ресурсов на сервере.
• REST обычно лучше всего использовать с ресурсо-ориентированной архитектурой (ROA). В этом способе мышления все является ресурсом, и вы будете оперировать этими ресурсами.
• Пока ваш язык программирования имеет библиотеку HTTP, а в большинстве своем она есть, вы можете очень легко использовать протокол HTTP REST.
• Двоичные данные или двоичные ресурсы могут быть просто доставлены по их запросу.

На Google < / а>.

Мне больше всего нравится эта. Обновление 27 ноября 2013 г .: сайт Пола Прескода, похоже, отключен, и эта статья больше не доступна, хотя копии можно найти на Wayback Machine или в виде PDF-файла на CiteSeerX.

ОТДЫХ

Я понимаю, что основная идея REST чрезвычайно проста. Мы использовали веб-браузеры в течение многих лет и убедились, насколько легкими, гибкими, производительными и т. Д. Бывают веб-сайты. HTML-сайты используют гиперссылки и формы в качестве основных средств взаимодействия с пользователем. Их главная цель - позволить нам, клиентам, знать только те ссылки, которые мы можем использовать в текущем состоянии. А REST просто говорит: «Почему бы не использовать те же принципы для управления клиентскими компьютерами через наше приложение?» Объедините это с мощью инфраструктуры WWW, и вы получите отличный инструмент для создания отличных распределенных приложений.

Другое возможное объяснение - для людей с математическим мышлением. Каждое приложение - это, по сути, машина состояний, в которой действиями бизнес-логики являются переходы между состояниями. Идея REST состоит в том, чтобы отображать каждый переход на некоторый запрос к ресурсу и предоставлять клиентам ссылки, представляющие переходы, доступные в текущем состоянии. Таким образом, он моделирует конечный автомат с помощью представлений и ссылок. Вот почему это называется REpresentational State Transfer.

Довольно удивительно, что все ответы, похоже, сосредоточены либо на формате сообщения, либо на использовании HTTP-глаголов. На самом деле формат сообщения вообще не имеет значения, REST может использовать любой, при условии, что разработчик сервиса его задокументирует. Глаголы HTTP делают службу только службой CRUD, но еще не RESTful. Что действительно превращает службу в службу REST, так это гиперссылки (также известные как элементы управления гипермедиа), встроенные в ответы сервера вместе с данными, и их количества должно быть достаточно, чтобы любой клиент мог выбрать следующее действие из этих ссылок.

К сожалению, довольно сложно найти правильную информацию о REST в Интернете, за исключением Диссертация Роя Филдинга. (Он тот, кто получил REST). Я бы порекомендовал книгу REST на практике как он дает исчерпывающее пошаговое руководство по переходу от SOAP к REST.

SOAP

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

По сравнению

Такие детали, как транспортные протоколы, форматы сообщений, xsd, wsdl и т. Д., Не имеют значения при сравнении любой формы RPC с REST. Основное отличие состоит в том, что служба RPC заново изобретает велосипед, создавая собственный протокол приложения в RPC API с семантикой, которую знает только он. Следовательно, все клиенты должны понимать этот протокол перед использованием службы, и никакая общая инфраструктура, такая как кеши, не может быть построена из-за проприетарной семантики всех запросов. Кроме того, API RPC не предлагают, какие действия разрешены в текущем состоянии, это должно быть получено из дополнительной документации. REST, с другой стороны, подразумевает использование унифицированных интерфейсов, позволяющих различным клиентам иметь некоторое представление о семантике API, и элементов управления гипермедиа (ссылок) для выделения доступных опций в каждом состоянии. Таким образом, он позволяет кэшировать ответы для масштабирования сервисов и сделать правильное использование API легко обнаруживаемым без дополнительной документации.

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

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

Обновить

Мой опыт неожиданно показал, что разработка REST сложнее, чем SOAP. По крайней мере, для .NET. Хотя существуют отличные фреймворки, такие как веб-API ASP.NET, нет инструментов, которые автоматически генерировали бы прокси на стороне клиента. Ничего подобного «Добавить ссылку на веб-службу» или «Добавить ссылку на службу WCF». Приходится писать весь код сериализации и запроса сервисов вручную. И, черт возьми, это много шаблонного кода. Я думаю, что для разработки REST необходимо что-то похожее на WSDL и реализацию инструментов для каждой платформы разработки. На самом деле, похоже, есть хорошая основа: WADL или WSDL 2.0, но ни один из стандартов не поддерживается.

Обновление (январь 2016 г.)

Оказывается, теперь существует широкий спектр инструментов для определения REST API. . В настоящее время я предпочитаю RAML.

Как работают веб-службы

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

Это самое простое объяснение, которое вы когда-либо найдете.

Эта статья представляет собой повествование от мужа к жене, в котором муж объясняет своей жене об отдыхе в чисто непрофессиональных терминах. Должны прочитать!

как-я-объяснил-отдых-моей-жене (исходная ссылка)
как-я-объяснил-отдых- to-my-wife (рабочая ссылка 19.07.2013)

SOAP - протокол простого доступа к объектам - это протокол!

REST - REpresentational State Transfer - это архитектурный стиль!

SOAP - это протокол XML, используемый для передачи сообщений, обычно через HTTP.

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

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

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

Связь клиент-сервер

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

Без гражданства

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

Кэшируемый

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

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

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

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

Дополнительную информацию о ОТДЫХ и вышеперечисленные пункты.

Мне нравится ответ Брайана Р. Бонди. Я просто хотел добавить, что Википедия дает четкое описание REST. Статья отличает его от SOAP.

REST - это максимально простой обмен информацией о состоянии.

SOAP - это протокол сообщений, использующий XML.

Одна из основных причин, по которой многие люди перешли с SOAP на REST, заключается в том, что стандарты WS- * (называемые WS splat), связанные с веб-службами на основе SOAP, ЧРЕЗВЫЧАЙНО сложны. Список спецификаций см. В wikipedia. Каждая из этих спецификаций очень сложна.

РЕДАКТИРОВАТЬ: по какой-то причине ссылки отображаются неправильно. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

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

МЫЛО

SOAP («простой» протокол доступа к объектам) - это протокол (а стандарт W3C). Он определяет, как создавать, отправлять и обрабатывать сообщения SOAP.

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

• Сообщения SOAP передаются как сообщения HTTP с подтипом SOAP + XML MIME. Эти HTTP-сообщения могут быть составными, поэтому при желании мы можем прикреплять файлы к SOAP-сообщениям.

• Очевидно, что мы используем архитектуру клиент-сервер, поэтому клиенты SOAP отправляют запросы на веб-серверы SOAP, а службы отправляют ответы клиентам. Большинство веб-сервисов используют файл WSDL для описания сервиса. Файл WSDL содержит схему XML (далее XSD) данных, которые мы хотим отправить, и привязку WSDL, которая определяет, как веб-сервис привязан к протоколу HTTP. Есть два стиля привязки : RPC и документ. Благодаря привязке стиля RPC тело SOAP содержит представление вызова операции с параметрами (HTTP-запросы) или возвращаемыми значениями (HTTP-ответ). Параметры и возвращаемые значения проверяются на соответствие XSD. Благодаря привязке стиля документа тело SOAP содержит XML-документ, который проверяется на соответствие XSD. Я думаю, что стиль привязки документа лучше подходит для систем, основанных на событиях, но я никогда не использовал этот стиль привязки. Стиль привязки RPC более распространен, поэтому большинство людей используют SOAP для целей XML / RPC в распределенных приложениях. Веб-службы обычно находят друг друга, запрашивая сервер UDDI. Серверы UDDI - это реестры, в которых хранится местоположение веб-сервисов.

SOAP RPC

Итак, на мой взгляд, наиболее распространенный веб-сервис SOAP использует стиль привязки RPC и буквальный стиль кодирования и имеет следующие свойства:

• Он сопоставляет URL-адреса с операциями.
• Он отправляет сообщения с подтипом SOAP + XML MIME.
• У него может быть хранилище сеансов на стороне сервера, в этом нет никаких ограничений.
• Драйверы клиента SOAP используют WSDL-файл службы для преобразования операций RPC в методы. Приложение на стороне клиента взаимодействует с веб-службой SOAP, вызывая эти методы. Таким образом, большинство клиентов SOAP ломаются из-за изменений интерфейса (результирующих изменений имен методов и / или параметров).
• Можно написать клиентов SOAP, которые не будут ломаться из-за изменений интерфейса, используя RDF и найдут операции по семантике, но семантический веб-сервис очень редки, и у них не обязательно есть постоянный клиент (я думаю).

ОТДЫХАТЬ

REST (репрезентативная передача состояния) - это архитектурный стиль, описанный в диссертации в Рой Филдинг. Это не касается протоколов, таких как SOAP. Он начинается с нулевого стиля архитектуры, не имеющего ограничений, и определяет ограничения архитектуры REST одно за другим. Люди используют термин RESTful для веб-сервисов, которые соответствуют всем ограничениям REST, но, по словам Роя Филдинга, не существует таких вещей, как уровни REST < / а>. Когда веб-сервис не соответствует всем ограничениям REST, это не REST веб-сервис.

Ограничения REST

• Клиент-серверная архитектура - думаю, эта часть всем знакома. Клиенты REST обмениваются данными с веб-службами REST, веб-службы поддерживают общие данные - состояние ресурсов в дальнейшем - и обслуживают их клиентов.
• Без сохранения состояния - часть аббревиатуры "передача состояния": REST. Клиенты поддерживают состояние клиента (состояние сеанса / приложения), поэтому службы не должны иметь хранилища сеансов. Клиенты передают соответствующую часть состояния клиента при каждом запросе службам, которые отвечают соответствующей частью состояния ресурса (поддерживаемой ими). Таким образом, запросы не имеют контекста, они всегда содержат информацию, необходимую для их обработки. Например, при базовой аутентификации HTTP имя пользователя и пароль хранятся у клиента, и он отправляет их с каждым запросом, поэтому аутентификация происходит по каждому запросу. Это сильно отличается от обычных веб-приложений, где аутентификация происходит только при входе в систему. Мы можем использовать любой механизм хранения данных на стороне клиента, такой как в памяти (javascript), файлы cookie, localStorage и так далее ... для сохранения некоторых частей состояния клиента, если мы хотим. Причина ограничения безгражданства в том, что сервер хорошо масштабируется - даже при очень высокой нагрузке (миллионы пользователей) - когда ему не нужно поддерживать сеанс каждого отдельного клиента.
• Кэш - ответ должен содержать информацию о том, может быть кэширован клиент или нет. Это дополнительно улучшает масштабируемость.

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

  • Identification of resources - REST resource is the same as RDF resource. According to Fielding if you can name something, then it can be a resource, for example: "the current local weather" can be a resource, or "your mobile phone" can be a resource, or "a specific web document" can be a resource. To identify a resource you can use resource identifiers: URLs and URNs (for example ISBN number by books). A single identifier should belong only to a specific resource, but a single resource can have many identifiers, which we frequently exploit for example by pagination with URLs like https://example.com/api/v1/users?offset=50&count=25. URLs have some specifications, for example URLs with the same pathes but different queries are not identical, or the path part should contain the hierarhical data of the URL and the query part should contain the non-hierarchical data. These are the basics of how to create URLs by REST. Btw. the URL structure does matter only for the service developers, a real REST client does not concern with it. Another frequently asked question is API versioning, which is an easy one, because according to Fielding the only constant thing by resource is semantics. If the semantics change, then you can add a new version number. You can use classical 3 number versioning and add only the major number to the URLs (https://example.com/api/v1/). So by backward compatible changes nothing happens, by non-backward compatible changes you will have a non-backward compatible semantics with a new API root https://example.com/api/v2/. So the old clients won't break, because they can use the https://example.com/api/v1/ with the old semantics.
  • Управление ресурсами с помощью представлений. Вы можете управлять данными, связанными с ресурсами (состоянием ресурса), отправляя предполагаемое представление ресурсов вместе с методом HTTP и идентификатором ресурса в службу REST. Например, если вы хотите переименовать пользователя после вступления в брак, вы можете отправить запрос PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}, где {name: "Mrs Smith"} - это JSON-представление предполагаемого состояния ресурса, другими словами: новое имя. Это происходит наоборот, служба отправляет представления ресурсов клиентам, чтобы изменить их состояния. Например, если мы хотим прочитать новое имя, мы можем отправить GET https://example.com/api/v1/users/1?fields="name" поисковый запрос, который приведет к ответу 200 ok, {name: "Mrs Smith"}. Таким образом, мы можем использовать это представление для изменения состояния клиента, например, мы можем отобразить «Добро пожаловать на нашу страницу, миссис Смит!». сообщение. Ресурс может иметь множество представлений в зависимости от идентификатора ресурса (URL) или заголовка accept, который мы отправили с запросом. Например, мы можем отправить изображение миссис Смит (возможно, не обнаженной), если будет запрошено image/jpeg.
  • Самоописательные сообщения - сообщения должны содержать информацию о том, как их обрабатывать. Например, метод URI и HTTP, заголовок типа содержимого, заголовки кеша, RDF, который описывает значение данных и т. Д. Важно использовать стандартные методы. Важно знать спецификацию методов HTTP. Например, GET означает получение информации, идентифицированной URL-адресом запроса, DELETE означает запрос сервера на удаление ресурса, идентифицированного данным URL-адресом, и так далее ... коды состояния HTTP имеют спецификация, например 200 означает успех, 201 означает создание нового ресурса, 404 означает, что запрошенный ресурс не был найден на сервере и т. д. Использование существующих стандартов - важная часть REST.

  • Гипермедиа как механизм состояния приложения (далее HATEOAS). Гипермедиа - это тип мультимедиа, который может содержать гиперссылки. В Интернете мы следуем ссылкам, описываемым гипермедийным форматом (обычно HTML), для достижения цели, вместо того, чтобы вводить URL-адреса в адресную строку. REST следует той же концепции, представления, отправленные службой, могут содержать гиперссылки. Мы используем эти гиперссылки для отправки запросов в службу. В ответ мы получаем данные (и, возможно, больше ссылок), которые мы можем использовать для создания нового состояния клиента и так далее ... Вот почему гипермедиа является движком состояния приложения (состояния клиента). Вы, наверное, задаетесь вопросом, как клиенты узнают гиперссылки и переходят по ним? Для людей это довольно просто: мы читаем заголовок ссылки, возможно, заполняем поля ввода, а после этого всего лишь один щелчок. На машинах мы должны добавлять семантику к ссылкам с помощью RDF (с помощью JSON-LD с Hydra) или с помощью специальных решений для гипермедиа (например, Отношения ссылок IANA и типы MIME, специфичные для поставщика, от HAL+JSON). Существует множество машиночитаемых XML и форматы гипермедиа JSON, вот лишь краткий их список:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Сирена
    • Коллекция + JSON

    Иногда сложно выбрать ...

• Многоуровневая система - мы можем использовать несколько уровней между клиентами и службами. Никто из них не должен знать обо всех этих дополнительных слоях, только о слое рядом с ним. Эти уровни могут улучшить масштабируемость, применяя кеши и балансировку нагрузки, или они могут применять политики безопасности.
• Код по запросу - мы можем отправить обратно код, который расширяет функциональные возможности клиента, например код javascript для браузера. Это единственное необязательное ограничение REST.

Веб-сервис REST - различия веб-сервисов SOAP RPC

Таким образом, веб-сервис REST сильно отличается от веб-сервиса SOAP (со стилем привязки RPC и буквальным стилем кодирования)

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

и так далее...

Веб-сервис SOAP RPC не соответствует всем ограничениям REST:

• клиент-серверная архитектура - всегда
• без состояния - возможно
• кеш - возможно
• единый интерфейс - никогда
• многоуровневая система - никогда
• код по запросу (необязательно) - возможно

Я начну со второго вопроса: Что такое веб-службы? по очевидным причинам.

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

Следующая Ссылка очень наглядно рассказывает о REST и SOAP.

REST против SOAP

Если вы также хотите знать, когда выбрать, что (REST или SOAP), еще одна причина пройти через это!

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

REST делает это, используя методы, которые напоминают взаимодействие вашего браузера с веб-серверами: использование GET для запроса веб-страницы, POSTing в полях формы и т. Д.

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

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

Я думаю, что это настолько просто, насколько я могу это объяснить. Пожалуйста, любой может поправить меня или добавить к этому.

SOAP - это формат сообщений, используемый отключенными системами (например, в Интернете) для обмена информацией / данными. Это работает с XML-сообщениями, перемещающимися туда и обратно.

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

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

SOAP - "Простой протокол доступа к объектам"

SOAP - это небольшая передача сообщений или небольших объемов информации через Интернет. Сообщения SOAP отформатированы в XML и обычно отправляются с управлением по HTTP.

REST - «REpresentational State Transfer»

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

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

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

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

Контракты между системами в совокупности называются метаданными и включают описания услуг, поддерживаемые шаблоны обмена сообщениями и политики, регулирующие качество обслуживания (услугу может потребоваться шифрование, надежная доставка и т. Д.). Описание услуги, в свою очередь, является подробным. спецификация данных (документов сообщений), которые будут отправлены и получены системой. Документы описываются с использованием языка описания XML, такого как определение схемы XML. Пока все системы соблюдают свои опубликованные контракты, они могут взаимодействовать, и изменения во внутреннем устройстве систем никогда не влияют на другие. Каждая система отвечает за перевод собственных внутренних реализаций в свои контракты и обратно.

REST - Перенос состояния репрезентации. Физический протокол - HTTP. По сути, REST - это все отдельные ресурсы в Интернете, которые однозначно идентифицируются по URL-адресу. Все операции, которые могут быть выполнены с этими ресурсами, можно описать ограниченным набором глаголов (глаголов «CRUD»), которые, в свою очередь, сопоставляются с глаголами HTTP.

REST гораздо менее «тяжеловесен», чем SOAP.

Работа веб-службы