web-services - чайников - soap wsdl




SOAP vs REST(различия) (8)

Я прочитал статьи о различиях между SOAP и REST в качестве протокола обмена веб-сервисами, но я думаю, что самые большие преимущества для REST над SOAP:

  1. REST более динамичен, нет необходимости создавать и обновлять UDDI.

  2. REST не ограничивается форматом XML. Веб-службы REST могут отправлять простой текст, JSON, а также XML.

Но SOAP более стандартизирован (Ex; безопасность).

Итак, я прав в этих пунктах?


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

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

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

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

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

<name>Arin</name>

или же

"name": "Arin"

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

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

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

Теперь SOAP поддерживает единственный XML, но он также имеет свои преимущества.

В самом деле! Как?

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

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

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

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

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

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

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

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

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

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

Вот «Учебное пособие по Java EE 6», где они сказали, что дизайн RESTful может быть подходящим, когда выполняются следующие условия . Посмотри.

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


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

++ Ошибка, которая часто возникает при приближении к REST, заключается в том, чтобы думать о ней как о «веб-сервисах с URL-адресами» - думать о REST как о другом механизме удаленного вызова процедур (RPC), таком как SOAP, но вызывается через простые URL-адреса HTTP и без SOAP Пространства имен XML.

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


К сожалению, в REST существует много дезинформации и неправильных представлений. Не только ваш вопрос и ответ от @cmd отражают их, но и большинство вопросов и ответов, связанных с предметом в .

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

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

Клиент REST больше похож на браузер. Это общий клиент, который знает, как использовать протокол и стандартизованные методы, и приложение должно соответствовать этому. Вы не нарушаете стандарты протокола, создавая дополнительные методы, вы используете стандартные методы и создаете с ними действия по типу вашего медиа. Если все сделано правильно, есть меньше связей, и изменения могут быть рассмотрены более изящно. Предполагается, что клиент должен войти в службу REST с нулевым знанием API, за исключением точки входа и типа носителя. В SOAP клиенту нужны предыдущие знания обо всем, что он будет использовать, или он даже не начнет взаимодействие. Кроме того, клиент REST может быть расширен по коду по требованию, предоставленному самим сервером, классическим примером является код JavaScript, используемый для управления взаимодействием с другой службой на стороне клиента.

Я думаю, что это решающие моменты, чтобы понять, что такое REST, и как он отличается от SOAP:

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

  • REST не является отображением методов CRUD в HTTP. Прочтите this ответ, чтобы получить подробное объяснение.

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

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

  • REST - это архитектурный стиль самого веб-сайта. Когда вы вводите , вы знаете, что такое Пользователь, вопрос и ответ, вы знаете типы медиа, и веб-сайт предоставляет вам ссылки на них. API REST должен сделать то же самое. Если мы разработали Интернет так, как люди думают, что REST должен быть сделан, вместо того, чтобы иметь домашнюю страницу со ссылками на вопросы и ответы, у нас была бы статическая документация, поясняющая, что для того, чтобы просмотреть вопрос, вы должны взять UIV .com/questions/<id> , замените id на Question.id и вставьте его в свой браузер. Это глупость, но это то, что многие считают REST.

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

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

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


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

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


Разница между отдыхом и мылом

МЫЛО

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

ОСТАЛЬНОЕ

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

Для получения дополнительной информации см. here


Решение между ними станет вашим первым выбором при разработке веб-сервиса, поэтому важно понять плюсы и минусы этих двух. Также важно, в раздутых дискуссиях между двумя философиями, отделить реальность от риторики.

Основы REST

  • Все в REST рассматривается как ресурс.
  • Каждый ресурс идентифицируется с помощью URI.
  • Использует единые интерфейсы. Ресурсы обрабатываются с помощью операций POST, GET, PUT, DELETE, которые аналогичны операциям Create, Read, Update и Delete (CRUD).
  • Будьте без гражданства. Каждый запрос является независимым запросом. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса.
  • Коммуникации выполняются через представления. Например, XML, JSON RESTful Web Services. Веб-службы RESTful основаны на методах HTTP и концепции REST. Веб-служба RESTful обычно определяет базовый URI для служб; поддерживаемые MIME-типы (XML, текст, JSON, пользовательские, ...) и набор операций (POST, GET, PUT, DELETE), которые поддерживаются.

Основы SOAP

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

SOAP vs REST?

Одним из основных преимуществ SOAP является то, что у вас есть описание службы WSDL. Вы можете в значительной степени обнаружить службу автоматически и создать полезный клиентский прокси из этого описания службы (сгенерировать вызовы служб, необходимые типы данных для методов и т. Д.). Обратите внимание, что с версией 2.0 WSDL поддерживает все HTTP-глаголы и может использоваться для документирования служб RESTful, но для этой цели в WADL (язык описания веб-приложений) существует менее сложная альтернатива.

С помощью служб RESTful безопасность сообщений обеспечивается транспортным протоколом (HTTPS) и только точка-точка. Он не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут реагировать на сбои в связи путем повторной попытки. SOAP имеет успешную / повторную логику и обеспечивает сквозную надежность даже через посредников SOAP.

Одним из основных преимуществ API RESTful является гибкость представления данных, например, вы можете сериализовать свои данные в формате XML или JSON. API RESTful более чисты или понятны, потому что они добавляют элемент использования стандартизованных URI и придают важное значение используемому глаголу HTTP (т. Е. GET, POST, PUT и DELETE).

Службы RESTful также легки, то есть у них нет большой дополнительной разметки XML. Чтобы вызывать RESTful API все, что вам нужно, это браузер или HTTP-стек, и почти все устройства или машины, подключенные к сети, имеют это.

Преимущества REST

  • Поскольку REST использует стандартный HTTP, он намного проще в любом случае. Создание клиентов, разработка API-интерфейсов, документация намного легче понять, и не так много вещей, которые REST не делает проще / лучше, чем SOAP.
  • REST позволяет использовать много разных форматов данных, тогда как SOAP разрешает только XML. Хотя это может показаться, что это добавляет сложности для REST, потому что вам нужно обрабатывать несколько форматов, по моему опыту, это было очень полезно. JSON обычно лучше подходит для данных и анализирует гораздо быстрее. REST позволяет лучше поддерживать клиентов браузера благодаря поддержке JSON.
  • REST имеет лучшую производительность и масштабируемость. Чтение REST может быть кэшировано; Чтения на основе SOAP не могут быть кэшированы.
  • Нет дорогостоящих инструментов, требующих взаимодействия с веб-службой
  • Меньшая кривая обучения
  • Эффективный (SOAP использует XML для всех сообщений, REST может использовать более мелкие форматы сообщений)
  • Быстрое (не требуется большая обработка)
  • Ближе к другим веб-технологиям в философии дизайна

Преимущества SOAP

  • WS-Security: хотя SOAP поддерживает SSL (как и REST), он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия. Поддерживает идентификацию через посредников, а не только точку (SSL). Он также обеспечивает стандартную реализацию целостности данных и конфиденциальности данных. Вызов «Enterprise» не означает, что он более безопасен, он просто поддерживает некоторые инструменты безопасности, которым не нужны обычные интернет-сервисы, на самом деле они нужны только в нескольких «корпоративных» сценариях.
  • WS-AtomicTransaction: нужны транзакции ACID по сервису, вам понадобится SOAP. Хотя REST поддерживает транзакции, он не является таким всеобъемлющим и не совместим с ACID. К счастью, транзакции ACID почти никогда не имеют смысла в Интернете. REST ограничивается самим HTTP, который не может обеспечить двухфазное принятие через распределенные транзакционные ресурсы, но SOAP может. Интернет-приложениям не нужен этот уровень надежности транзакций, иногда это делают корпоративные приложения.
  • WS-ReliableMessaging: Rest не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут реагировать на сбои в связи путем повторной попытки. SOAP имеет успешную / повторную логику и обеспечивает сквозную надежность даже через посредников SOAP.
  • Язык, платформа и транспорт независимы (REST требует использования HTTP)
  • Хорошо работает в распределенных корпоративных средах (REST предполагает прямую связь «точка-точка»)
  • Стандартизированный
  • Обеспечивает значительную расширяемость до сборки в виде стандартов WS
  • Встроенная обработка ошибок
  • Автоматизация при использовании с некоторыми языковыми продуктами

Где использовать REST

районы, в которых работает REST:

  • Ограниченная полоса пропускания и ресурсы: помните, что структура возврата действительно в любом формате (разработчик определен). Кроме того, любой браузер можно использовать, поскольку подход REST использует стандартные команды GET, PUT, POST и DELETE. Опять же, помните, что REST также может использовать объект XMLHttpRequest, который поддерживает большинство современных браузеров, что добавляет бонус AJAX.
  • Операции без сохранения: если операция должна быть продолжена, то REST не лучший подход, и SOAP может поместиться лучше. Однако, если вам нужны операции CRUD (создание, чтение, обновление и удаление) без учета состояния, тогда это REST.
  • Ситуации кэширования: если информация может быть кэширована из-за безстоящей операции подхода REST, это идеально.

Где использовать SOAP

где SOAP работает как отличное решение:

  • Асинхронная обработка и вызов: если вашему приложению требуется гарантированный уровень надежности и безопасности, SOAP 1.2 предлагает дополнительные стандарты для обеспечения такого типа работы. Такие вещи, как WSRM - WS-Reliable Messaging.
  • Формальные контракты: если обе стороны (поставщик и потребитель) должны согласовать формат обмена, то SOAP 1.2 дает жесткие спецификации для такого типа взаимодействия.
  • Операции с состоянием: если для приложения требуется контекстная информация и управление диалоговым состоянием, то SOAP 1.2 имеет дополнительную спецификацию в структуре WS для поддержки этих вещей (безопасность, транзакции, координация и т. Д.). Сравнительно, подход REST заставил бы разработчиков построить эту обычную сантехнику.

  • SOAP - это протокол, тогда как REST - это архитектура.
  • SOAP предоставляет поведение, представляющее логику, тогда как REST предоставляет ресурсы, которые представляют данные.
  • С точки зрения потребления REST-сервис намного проще, чем SOAP. С REST накладные расходы на обработку конвертов XML устраняются, что делает его более быстрым по сравнению с SOAP.
  • SOAP предоставил хорошие параметры безопасности по сравнению с REST.
  • Для взаимодействия между машинами и машинами и корпоративными решениями SOAP предпочтительнее, но для публичного доступа REST - лучший вариант, почти 70% общедоступных API - это REST.
  • REST - легкий, обслуживаемый и масштабируемый.
  • REST не зависит от устройства, то есть клиент, использующий REST API, может быть чем-то вроде мобильных устройств, ноутбуков, телевизоров и т. Д.
  • С облаком в действии. Приложение медленно переходит в облачные системы, такие как Azure, Amazon AWS. Эти системы строят и выставляют REST API. Следовательно, это хороший шаг для создания приложения в верхней части REST API.

REST Vs SOAP


REST vs SOAP не является правильным вопросом.

REST , в отличие от SOAP , не является протоколом.

REST - это архитектурный стиль и дизайн сетевых архитектур.

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

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

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

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

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

Stateless

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

Cacheable

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

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

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

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

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

EDIT: обновление контента на основе комментариев





soap