Сравните и сравните веб-службы REST и SOAP?

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

Разница заключается в следующем:

  • SOAP - это протокол сообщений на основе XML, в то время как REST - это архитектурный стиль
  • SOAP использует WSDL для связи между потребителем и поставщиком, тогда как REST использует только XML или JSON для отправки и получения данных.
  • SOAP вызывает службы, вызывая метод RPC, REST просто вызывает вызовы через URL-адрес.
  • SOAP не возвращает читаемый человеком результат, в то время как результат REST читается с помощью простого XML или JSON
  • SOAP не просто через HTTP, он также использует другие протоколы, такие как SMTP, FTP и т.д., REST - только HTTP

Это все, что я знаю, как различия между ними. Может ли кто-нибудь исправить меня и добавить больше.

Ответ 1

SOAP использует WSDL для связи между потребителем и поставщиком btw, тогда как REST использует только XML или JSON для отправки и получения данных.

WSDL определяет контракт между клиентом и сервисом и статичен по своей природе. В случае контракта REST является несколько сложным и определяется HTTP, URI, Media Formats и Application Specific Coordination Protocol. Он очень динамичен, в отличие от WSDL.

SOAP не возвращает читаемый человеком результат, в то время как результат REST читается с помощью простого XML или JSON

Это неверно. Обычный XML или JSON не являются RESTful вообще. Ни один из них не определяет какие-либо элементы управления (например, ссылки и ссылки, информацию о методах, информацию о кодировании и т.д.), Что противоречит REST, поскольку сообщения должны быть автономными и координировать взаимодействие между агентом/клиентом и службой.

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

Не обязательно, чтобы сообщения были читабельны для человека, можно использовать критический формат и создавать совершенно правильные приложения REST. Не имеет значения, является ли сообщение понятным для человека или нет.

Таким образом, простой XML (application/xml) или JSON (application/json) не являются достаточными форматами для создания приложений REST. Всегда разумно использовать подмножество этих общих типов медиа, которые имеют сильное смысловое значение и предоставляют достаточную управляющую информацию (ссылки и т.д.) Для координации взаимодействия между клиентом и сервером.

REST - только HTTP

Не верно, HTTP наиболее широко используется, и когда мы говорим о веб-сервисах REST, мы просто принимаем HTTP. HTTP определяет интерфейс с его методами (GET, POST, PUT, DELETE, PATCH и т.д.) И различные заголовки, которые могут использоваться единообразно для взаимодействия с ресурсами. Эта равномерность может быть достигнута и с другими протоколами.

P.S. Очень простое, но очень интересное объяснение REST: http://www.looah.com/source/view/2284

Ответ 2

В повседневных практических условиях программирования наибольшая разница заключается в том, что с SOAP вы работаете со статическими и сильно определенными форматами обмена данными, где, как и при форматировании обмена данными REST и JSON, очень легко сравнивать. Например, с помощью SOAP вы можете проверить, что обменянные данные соответствуют схеме XSD. Таким образом, XSD выступает в качестве "контракта" о том, как клиент и сервер должны понимать, как должны быть структурированы обменные данные.

Данные JSON обычно не передаются в соответствии с строго определенным форматом (если вы не используете фреймворк, который его поддерживает.. например http://msdn.microsoft.com/en-us/library/jj870778.aspx или реализации json-схемы).

В самом деле, некоторые (многие/большинство) утверждают, что "динамический" секретный соус JSON противоречит философии/культуре ограничения его контрактами данных (Должен ли JSON RESTful веб-службы используют контракт с данными)

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

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

Ответ 3

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

Хотя SOAP обычно называют "веб-сервисами", это неправильное название. SOAP имеет очень мало общего с Интернетом. REST предоставляет настоящие "веб-службы" на основе URI и HTTP.

В качестве иллюстрации здесь приведены несколько вызовов и их соответствующий дом с комментариями.

getUser(User);

Это операция отдыха при доступе к ресурсу (данным).

switchCategory(User, OldCategory, NewCategory)

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