Ответ 1

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

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

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

Rest - передача состояния представления

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

Ответ 2

Оба метода используются многими крупными игроками. Это вопрос предпочтений. Я предпочитаю 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 г.: Сайт Paul Prescod, по-видимому, перешел в автономный режим, и эта статья больше не доступна, хотя копии можно найти на Wayback Machine или в формате PDF на CiteSeerX.

Ответ 3

REST

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

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

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

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

SOAP

Это одна из возможных форм архитектуры архитектуры 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, поэтому он является сервисом. Конечно, это решает некоторые проблемы (в противном случае почему бы кому-либо использовать веб-службу) для своих клиентов.

Ответ 4

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

В этой статье муж рассказывает жене повествование, где муж объясняет своей жене об ОТДЫХЕ, в чистом непрофессиональном плане. Обязательно прочитайте!

how-i-explain-rest-to-my-wife (оригинальная ссылка)
how-i-explained-rest-to-my-wife (2013-07-19 рабочая ссылка)

Ответ 5

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

ОТДЕЛ - Передача состояния презентаций - это архитектурный стиль!

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

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

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

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

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

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

Stateless

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

Cacheable

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

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

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

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

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

Ответ 6

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

REST - это обмен информацией о состоянии, сделанный как можно проще.

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

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

EDIT: по какой-то причине ссылки отображаются неправильно. REST = http://en.wikipedia.org/wiki/REST

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

Ответ 7

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

SOAP

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

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

• Сообщения SOAP перемещаются как HTTP-сообщения с подтипом MIME SOAP + XML. Эти 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 и находить операции по семантике, но семантический веб-сервис очень редки, t обязательно иметь невыполненный клиент (я думаю).

REST

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

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

• Клиент-серверная архитектура. Я думаю, эта часть знакома всем. Клиенты REST свяжутся с веб-службами REST, веб-службы поддерживают общее состояние данных - ресурс в дальнейшем - и обслуживают его для клиентов.
• Без гражданства - аббревиатура "передача состояния" абзаца: REST. Клиенты поддерживают состояние клиента (состояние сеанса/приложения), поэтому у служб не должно быть хранилища сеансов. Клиенты переносят соответствующую часть состояния клиента по каждому запросу в службы, которые отвечают соответствующей части состояния ресурса (поддерживаются ими). Поэтому запросы не имеют контекста, они всегда содержат необходимую информацию для их обработки. Например, по HTTP basic auth имя пользователя и пароль хранятся клиентом, и он отправляет их с каждым запросом, поэтому аутентификация происходит по каждому запросу. Это очень отличается от обычных веб-приложений, где аутентификация происходит только при входе в систему. Мы можем использовать любой механизм хранения данных на стороне клиента, например, в памяти (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, что является простым, потому что, согласно Fielding, единственная постоянная вещь по ресурсу - это семантика. Если семантика изменится, вы можете добавить новый номер версии. Вы можете использовать классическое 3-мерное число версий и добавить только основное число в URL-адреса (https://example.com/api/v1/). Таким образом, благодаря обратным совместимым изменениям ничего не происходит, благодаря изменениям, не связанным с обратной совместимостью, у вас будет несовместимая семантика с новым API root https://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.

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

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Siren
    • Коллекция + JSON

    Иногда трудно выбрать...

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

REST webservice - Различия в веб-сервисах SOAP RPC

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

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

и т.д.

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

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

Ответ 8

Хорошо, я начну со второго вопроса: что такое веб-службы?, по понятным причинам.

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

В следующей ссылке говорится о REST и SOAP в чрезвычайно ясной форме.

REST vs SOAP

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

Ответ 9

SOAP и REST ссылаются на способы взаимодействия разных систем.

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

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

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

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

REST - "Передача состояния препроцессора"

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

Ответ 14

Вот хороший пример, если вы знаете немного С#: массив DataTable (т.е. DataTable []), список DataTable (т.е. List...) и IEnumerable из DataTables (т.е. IEnumerable...) и DataSet - это одно и то же в json (они выглядели бы как [[..first table - это массив объектов...], [.. second table..], [. etc.....]]. В С# это совершенно разные вещи IEnumerable - это интерфейс, DataSet - совершенно другой класс.

Вопрос под рукой "какова цель?" Если вы хотите показать свою базу данных (или небольшую часть вашей базы данных) всему миру (скажем, вы - аэропорт, и вы хотите, чтобы каждый Джон, Джейн и Дик знали, как совершали посадку и отправления), вы наверняка захотите отправиться в путь. с JSON (отдых). Им действительно все равно, как вы храните ваши данные - они просто хотят, чтобы они были в json. С другой стороны, если это внутренняя служба внутри вашей компании, вы хотите, чтобы она была очень точной. Это может быть хорошей идеей предоставить конечную точку с интерфейсом или абстрактными классами для полиморфных целей. (скажем, ваша авиакомпания хочет, чтобы ее самолеты очень эффективно сообщали о погоде практически в режиме реального времени в ходе полета). конечно, вы хотите SOAP поверх WCF в этом случае. Эта ясность классов, интерфейсов, рефератов окупится с точки зрения внутреннего программирования и простоты.

Ответ 15

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

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

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

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

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

REST намного меньше "тяжеловеса", чем SOAP.

Работа с веб-сервисом