Передача представительного состояния (REST) и простой протокол доступа к объектам (SOAP)
15 ответов
Простое объяснение о SOAP и REST
SOAP - "Простой протокол доступа к объектам"
SOAP - это метод передачи сообщений или небольших объемов информации через Интернет. Сообщения SOAP форматируются в XML и обычно отправляются с использованием HTTP (протокол передачи гипертекста).
Отдых - Представительский государственный трансферт
Отдых - это простой способ отправки и получения данных между клиентом и сервером, и у него не очень много определенных стандартов. Вы можете отправлять и получать данные в формате 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, и большинство из них делает, вы можете очень легко использовать протокол REST HTTP.
- Двоичные данные или двоичные ресурсы могут быть просто доставлены по их запросу.
В REST vs SOAP идут бесконечные дебаты в Google.
Мой любимый этот. Обновление 27 ноября 2013 г.: Сайт Пола Прескода, по-видимому, перешел в автономный режим, и эта статья больше недоступна, хотя копии можно найти на Wayback Machine или в формате PDF на CiteSeerX.
ОСТАЛЬНОЕ
Я понимаю, что основная идея REST предельно проста. Мы годами пользовались веб-браузерами и видели, насколько просты, гибки, эффективны и т. Д. Веб-сайты. HTML-сайты используют гиперссылки и формы в качестве основного средства взаимодействия с пользователем. Их главная цель - позволить нам, клиентам, знать только те ссылки, которые мы можем использовать в текущем состоянии. А REST просто говорит: "Почему бы не использовать одни и те же принципы для управления компьютером, а не людьми, через наше приложение?" Добавьте к этому мощь инфраструктуры WWW, и вы получите потрясающий инструмент для создания великолепных распределенных приложений.
Другое возможное объяснение для математически мыслящих людей. Каждое приложение в основном представляет собой конечный автомат, в котором действия бизнес-логики являются переходами состояний. Идея REST состоит в том, чтобы отобразить каждый переход на некоторый запрос к ресурсу и предоставить клиентам ссылки, представляющие переходы, доступные в текущем состоянии. Таким образом, он моделирует конечный автомат через представления и ссылки. Вот почему это называется REpresentational State Transfer.
Удивительно, что все ответы, похоже, сосредоточены либо на формате сообщений, либо на использовании HTTP-глаголов. На самом деле, формат сообщения вообще не имеет значения, REST может использовать любой, при условии, что разработчик сервиса документирует его. HTTP-глаголы делают службу CRUD-сервисом, но еще не RESTful. Что действительно превращает службу в службу REST, так это гиперссылки (так называемые элементы управления гипермедиа), встроенные в ответы сервера вместе с данными, и их количество должно быть достаточным для того, чтобы любой клиент мог выбрать следующее действие из этих ссылок.
К сожалению, довольно сложно найти правильную информацию о REST в Интернете, за исключением тезиса Роя Филдинга. (Он тот, кто получил REST). Я бы порекомендовал книгу "ОТДЫХ на практике", так как она содержит подробное пошаговое руководство по переходу от SOAP к REST.
МЫЛО
Это одна из возможных форм стиля архитектуры RPC (удаленный вызов процедуры). По сути, это просто технология, которая позволяет клиентам вызывать методы сервера через сервисные границы (сеть, процессы и т. Д.), Как если бы они вызывали локальные методы. Конечно, он отличается от вызова локальных методов скоростью, надежностью и так далее, но идея в том, что все просто.
По сравнению
Такие детали, как транспортные протоколы, форматы сообщений, xsd, wsdl и т. Д., Не имеют значения при сравнении любой формы RPC с REST. Основное отличие состоит в том, что служба RPC заново изобретает велосипед, разрабатывая собственный протокол приложения в API RPC с семантикой, известной только ему. Поэтому все клиенты должны понимать этот протокол перед использованием сервиса, и никакая общая инфраструктура, такая как кэши, не может быть построена из-за проприетарной семантики всех запросов. Кроме того, API RPC не предлагают, какие действия разрешены в текущем состоянии, это должно быть получено из дополнительной документации. REST, с другой стороны, подразумевает использование унифицированных интерфейсов, позволяющих различным клиентам иметь некоторое представление о семантике API, и гипермедиа элементов управления (ссылки) для выделения доступных опций в каждом состоянии. Таким образом, он позволяет кэшировать ответы для масштабируемых сервисов и легко обнаруживать правильное использование API без дополнительной документации.
В некотором смысле, SOAP (как и любой другой RPC) - это попытка туннелирования через сервисную границу, рассматривая соединительные среды как черный ящик, способный передавать только сообщения. REST - это решение признать, что Интернет представляет собой огромную распределенную информационную систему, принять мир таким, какой он есть, и научиться владеть им, а не бороться с ним.
SOAP, кажется, отлично подходит для внутренних сетевых API, когда вы управляете как сервером, так и клиентами, и при этом взаимодействие не слишком сложное. Для разработчиков более естественно использовать его. Однако для публичного API, который используется многими независимыми сторонами, является сложным и большим, REST должен подходить лучше. Но это последнее сравнение очень нечеткое.
Обновить
Мой опыт неожиданно показал, что разработка REST сложнее, чем SOAP. По крайней мере, для.NET. В то время как существуют отличные фреймворки, такие как ASP.NET Web API, нет инструментов, которые бы автоматически генерировали прокси на стороне клиента. Ничего подобного "Добавить ссылку на веб-службу" или "Добавить ссылку на службу WCF". Нужно написать весь код сериализации и запроса сервисов вручную. И человек, это много шаблонного кода. Я думаю, что для разработки REST необходимо что-то похожее на WSDL и реализацию инструментов для каждой платформы разработки. На самом деле, кажется, что есть хорошая основа: WADL или WSDL 2.0, но ни один из стандартов не поддерживается.
Обновление (январь 2016 г.)
Оказывается, в настоящее время существует множество инструментов для определения REST API. Мое личное предпочтение в настоящее время RAML.
Как работают веб-сервисы
Ну, это слишком широкий вопрос, потому что он зависит от архитектуры и технологии, используемой в конкретном веб-сервисе. Но в целом, веб-сервис - это просто какое-то приложение в Интернете, которое может принимать запросы от клиентов и возвращать ответы. Он открыт для Интернета, поэтому это веб- сервис, и он обычно доступен 24/7, поэтому это сервис. Конечно, это решает некоторую проблему (иначе зачем кому-то когда-либо использовать веб-сервис) для своих клиентов.
Это самое простое объяснение, которое вы когда-либо найдете.
В этой статье рассказывается о повествовании мужа и жены, где муж рассказывает своей жене о ОТДЫХ в чистом виде. Должен прочитать!
как я объяснил отдых моей жене (оригинальная ссылка)
как я объяснил отдых моей жене (рабочая ссылка 2013-07-19)
SOAP - Простой протокол доступа к объектам - это протокол!
ОТДЫХ - REpresentational State Transfer - архитектурный стиль!
SOAP это протокол XML, используемый для передачи сообщений, обычно через HTTP
REST а также SOAP возможно не взаимоисключающие. RESTful архитектура может использовать HTTP или же SOAP или какой-то другой протокол связи. REST оптимизирован для Интернета и, таким образом, HTTP это идеальный выбор. HTTP это также единственный протокол, обсуждаемый в статье Роя Филдинга.
Хотя REST и SOAP явно очень разные, этот вопрос освещает тот факт, что REST а также HTTP часто используются в тандеме. В первую очередь это связано с простотой HTTP и его очень естественным отображением в соответствии с принципами RESTful.
Основные принципы ОТДЫХА
Связь клиент-сервер
Клиент-серверные архитектуры имеют очень четкое разделение проблем. Все приложения, созданные в стиле RESTful, также должны быть клиент-серверными в принципе.
Stateless
Каждый запрос клиента к серверу требует, чтобы его состояние было полностью представлено. Сервер должен быть в состоянии полностью понять запрос клиента, не используя контекст сервера или состояние сеанса сервера. Отсюда следует, что все состояние должно быть сохранено на клиенте. Мы обсудим представление без гражданства более подробно позже.
Cacheable
Могут использоваться ограничения кэширования, что позволяет помечать данные ответа как кэшируемые или не кэшируемые. Любые данные, помеченные как кэшируемые, могут быть повторно использованы в качестве ответа на тот же последующий запрос.
Единый интерфейс
Все компоненты должны взаимодействовать через единый единый интерфейс. Поскольку взаимодействие всех компонентов происходит через этот интерфейс, взаимодействие с различными сервисами очень просто. Интерфейс такой же! Это также означает, что изменения реализации могут быть сделаны изолированно. Такие изменения не будут влиять на взаимодействие основных компонентов, потому что единый интерфейс всегда неизменен. Одним из недостатков является то, что вы застряли с интерфейсом. Если для конкретного сервиса может быть обеспечена оптимизация путем изменения интерфейса, вам не повезло, поскольку REST запрещает это. С другой стороны, REST оптимизирован для Интернета, поэтому невероятно популярны REST по HTTP!
Вышеупомянутые концепции представляют собой определяющие характеристики REST и отличают архитектуру REST от других архитектур, таких как веб-сервисы. Полезно отметить, что REST-сервис является веб-сервисом, но веб-сервис не обязательно является REST-сервисом.
См. Этот пост в блоге о принципах дизайна REST для получения более подробной информации о REST и вышеупомянутых пунктах.
Мне нравится ответ Брайана Р. Бонди. Я просто хотел добавить, что Википедия дает четкое описание REST. Статья отличает его от SOAP.
REST - это обмен информацией о состоянии, осуществляемый максимально просто.
SOAP - это протокол сообщений, который использует XML.
Одна из главных причин того, что многие люди перешли с SOAP на REST, заключается в том, что стандарты WS-* (называемые WS splat), связанные с веб-службами на основе SOAP, чрезвычайно сложны. См. Википедию для списка спецификаций. Каждая из этих спецификаций очень сложна.
РЕДАКТИРОВАТЬ: по какой-то причине ссылки не отображаются правильно. 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-документы с определенной структурой: они содержат конверт, содержащий заголовок и раздел body. Тело содержит фактические данные, которые мы хотим отправить, в формате 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), куки, localStorage и т. Д., Чтобы сохранить некоторые части состояния клиента, если мы захотим. Причина ограничения безгражданства в том, что сервер хорошо масштабируется - даже при очень высокой нагрузке (миллионы пользователей) - когда ему не нужно поддерживать сеанс каждого отдельного клиента.
- Кэш - ответ должен содержать информацию о том, может ли клиент быть кэширован или нет. Это улучшает масштабируемость в дальнейшем.
Единый интерфейс
- Идентификация ресурсов - ресурс REST такой же, как ресурс RDF. Согласно Филдингу, если вы можете назвать что-то, то это может быть ресурс, например: "текущая местная погода" может быть ресурсом, или "ваш мобильный телефон" может быть ресурсом, или "конкретный веб-документ" может быть ресурс. Для идентификации ресурса вы можете использовать идентификаторы ресурса: URL и URN (например, номер ISBN по книгам). Один идентификатор должен принадлежать только определенному ресурсу, но у одного ресурса может быть много идентификаторов, которые мы часто используем, например, при разбивке на страницы с такими URL-адресами, как
https://example.com/api/v1/users?offset=50&count=25, URL-адреса имеют некоторые характеристики, например, URL-адреса с одинаковыми путями, но разные запросы не идентичны, или часть пути должна содержать иерархические данные URL-адреса, а часть запроса должна содержать неиерархические данные. Это основы того, как создавать URL-адреса с помощью REST. Btw. структура URL имеет значение только для разработчиков сервиса, реальный клиент REST не имеет к этому отношения. Другой часто задаваемый вопрос - версионирование API, которое является простым, потому что согласно Филдингу единственная постоянная вещь по ресурсу - это семантика. Если семантика изменится, вы можете добавить новый номер версии. Вы можете использовать классическую версию с 3 номерами и добавить только основной номер в URL (https://example.com/api/v1/). Таким образом, с изменениями с обратной совместимостью ничего не происходит, с изменениями без обратной совместимости вы будете иметь семантику с обратной совместимостью с новым корнем APIhttps://example.com/api/v2/, Таким образом, старые клиенты не сломаются, потому что они могут использоватьhttps://example.com/api/v1/со старой семантикой. - Управление ресурсами с помощью представлений. Вы можете манипулировать данными, связанными с ресурсами (состоянием ресурсов), отправляя намеченное представление ресурсов - вместе с методом 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, только их краткий список:
Иногда трудно выбрать...
- Идентификация ресурсов - ресурс REST такой же, как ресурс RDF. Согласно Филдингу, если вы можете назвать что-то, то это может быть ресурс, например: "текущая местная погода" может быть ресурсом, или "ваш мобильный телефон" может быть ресурсом, или "конкретный веб-документ" может быть ресурс. Для идентификации ресурса вы можете использовать идентификаторы ресурса: URL и URN (например, номер ISBN по книгам). Один идентификатор должен принадлежать только определенному ресурсу, но у одного ресурса может быть много идентификаторов, которые мы часто используем, например, при разбивке на страницы с такими URL-адресами, как
- Многоуровневая система - мы можем использовать несколько слоев между клиентами и сервисами. Никто из них не должен знать обо всех этих дополнительных слоях, просто о слое рядом с ним. Эти уровни могут улучшить масштабируемость за счет применения кэшей и балансировки нагрузки, или они могут применять политики безопасности.
- Код по запросу - мы можем отправить обратно код, который расширяет функциональные возможности клиента, например, код 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:
Хорошо, я начну со второго вопроса: что такое веб-сервисы? по понятным причинам.
WebServices - это, по сути, кусочки логики (которую вы можете смутно называть методом), которая предоставляет определенные функции или данные. Реализующему клиенту (технически говоря, слово " потребляющий") просто необходимо знать, какой параметр (параметры) будет принимать метод и тип данных, которые он будет возвращать (если он вообще это сделает).
Следующая ссылка говорит все о 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 - это элементарный процесс возможной случайности и получения информации между вентилятором и сервером, и он не имеет однозначно определенных стандартов. Вы можете отправлять и принимать информацию в формате JSON, XML или даже в виде простого текста. Это легкий вес по сравнению с SOAP.
Вот хороший пример, если вы знаете немного C#: массив DataTable (т. Е. DataTable[]), список DataTable (т. Е. List...) и IEnumerable из DataTables (т. Е. IEnumerable...) и DataSet - это одно и то же. в json (они бы выглядели так [[..первая таблица - это массив объектов...], [.. вторая таблица..], [. etc.....] ]. В C# это совершенно разные вещи IEnumerable - это интерфейс, DataSet - совершенно другой класс.
Вопрос под рукой - "какова цель?". Если вы хотите показать свою базу данных (или небольшую часть вашей базы данных) всему миру (скажем, вы являетесь аэропортом, и вы хотите, чтобы каждый Джон, Джейн и Дик знали, как совершали посадку и отправления), вы наверняка захотите отправиться в путь. с JSON (отдых). Им действительно все равно, как вы храните ваши данные - они просто хотят, чтобы они были в json. С другой стороны, если это внутренняя служба внутри вашей компании, вы хотите, чтобы она была очень точной. Хорошей идеей может быть предоставление конечной точки с интерфейсом или абстрактных классов для полиморфных целей. (скажем, ваша авиакомпания хочет, чтобы ее самолеты очень эффективно сообщали о погоде практически в режиме реального времени в ходе полета). конечно, вы хотите SOAP поверх WCF в этом случае. Эта ясность классов, интерфейсов, рефератов окупится с точки зрения внутреннего программирования и простоты.
Веб-сервисы на основе SOAP Вкратце, модель Сервисов на основе SOAP рассматривает мир как экосистему равноправных партнеров, которые не могут контролировать друг друга, но должны работать вместе, выполняя опубликованные контракты. Это действительная модель беспорядочного реального мира, и контракты на основе метаданных формируют SOAP Service Interface.
мы все еще можем связывать SOAP с удаленными вызовами процедур на основе XML, но технология веб-служб на основе SOAP превратилась в гибкую и мощную модель обмена сообщениями.
SOAP предполагает, что все системы являются независимыми, и ни одна система не имеет никаких знаний о внутренностях другой и внутренней функциональности. Самое большее, что могут сделать такие системы - это отправлять сообщения друг другу и надеяться, что с ними будут действовать. Системы публикуют контракты, которые они обязуются соблюдать, и другие системы полагаются на эти контракты для обмена сообщениями с ними.
Контракты между системами в совокупности называются метаданными и включают описания услуг, поддерживаемые шаблоны обмена сообщениями и политики, определяющие качество обслуживания (услуга может нуждаться в шифровании, надежной доставке и т. Д.) Описание услуги, в свою очередь, является подробным указание данных (документов сообщения), которые будут отправлены и получены системой. Документы описываются с использованием языка описания XML, такого как определение схемы XML. Пока все системы выполняют свои опубликованные контракты, они могут взаимодействовать, и изменения во внутренних системах никогда не влияют ни на какие другие. Каждая система отвечает за перевод своих внутренних реализаций в свои контракты и из них.
ОТДЫХ - REpresentational State Transfer. Физический протокол HTTP. По сути, REST - это все отдельные ресурсы в сети, которые уникально идентифицируются по URL. Все операции, которые могут быть выполнены с этими ресурсами, могут быть описаны ограниченным набором глаголов (глаголами "CRUD"), которые, в свою очередь, отображаются на глаголы HTTP.
REST гораздо менее "тяжелый", чем SOAP.