В предыдущих руководствах было дано много подробностей о двух ключевых типах дизайна веб-сервисов. Одним из них является протокол SOAP (простой протокол доступа к объектам), а другим — REST для передачи представительного состояния.
Каждая техника имеет свои преимущества и недостатки. Следовательно, всегда хорошо понимать, в каких ситуациях следует использовать каждый дизайн. В этом руководстве рассматриваются некоторые ключевые различия между этими методами, а также проблемы, с которыми вы можете столкнуться при их использовании.
В этом уроке вы узнаете
- МЫЛО против ОТДЫХА
- Когда использовать REST и когда использовать SOAP
- Проблемы SOAP и REST API
- Разница между SOAP против CORBA Vs. DCOM Vs. Java RMI
МЫЛО против ОТДЫХА
Давайте кратко рассмотрим, как мыло против отдыха, прежде чем мы углубимся в ключевые различия между ними.
SOAP — SOAP — это протокол, который был разработан до REST и вошел в картину. Основная идея разработки SOAP заключалась в том, чтобы программы, созданные на разных платформах и языках программирования, могли легко обмениваться данными.
REST — это было разработано специально для работы с такими компонентами, как медиа-компоненты, файлы или даже объекты на определенном аппаратном устройстве. Любой веб-сервис, определенный на принципах REST, может называться веб-сервисом RestFul. Служба Restful будет использовать обычные HTTP-глаголы GET, POST, PUT и DELETE для работы с необходимыми компонентами.
Ниже приведены основные различия между SOAP и REST.
|
|
|
|---|---|
|
|
|
|
|
|
|
http://demo.guru99.com/Employee http://demo.guru99.com/Employee/1 |
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV ="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle =" http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <Demo.guru99WebService xmlns="http://tempuri.org/"> <EmployeeID>int</EmployeeID> </Demo.guru99WebService> </soap:Body> </SOAP-ENV:Envelope> |
{ «Город»: «Мумбаи», «государство»: «Махараштра»} |
|
|
Когда использовать REST и когда использовать SOAP
Одна из самых обсуждаемых тем — когда следует использовать REST или когда использовать SOAP при разработке веб-сервисов.
Ниже приведены некоторые из ключевых факторов, определяющих, когда каждая технология должна использоваться для веб-служб. Службы REST следует использовать в следующих случаях.
-
Ограниченные ресурсы и пропускная способность — поскольку сообщения SOAP имеют более тяжелый контент и потребляют гораздо большую пропускную способность, REST следует использовать в тех случаях, когда пропускная способность сети является ограничением.
-
Безгражданство — если нет необходимости поддерживать состояние информации от одного запроса к другому, следует использовать REST. Если вам нужен правильный информационный поток, в котором некоторая информация из одного запроса должна перетекать в другой, тогда SOAP больше подходит для этой цели. Мы можем взять пример любого сайта онлайн-покупки. Эти сайты обычно требуют, чтобы пользователь сначала добавил товары, которые необходимо приобрести в корзину. Все элементы корзины затем переносятся на страницу оплаты для совершения покупки. Это пример приложения, которому требуется функция состояния. Состояние товаров в корзине необходимо перенести на страницу оплаты для дальнейшей обработки.
-
Кэширование — если необходимо кэшировать большое количество запросов, тогда REST является идеальным решением. Время от времени клиенты могут запрашивать один и тот же ресурс несколько раз. Это может увеличить количество запросов, отправляемых на сервер. Благодаря реализации кэша результаты наиболее частых запросов могут быть сохранены в промежуточном местоположении. Поэтому, когда клиент запрашивает ресурс, он сначала проверяет кеш. Если ресурсы существуют, они не будут переданы на сервер. Таким образом, кэширование может помочь минимизировать количество обращений к веб-серверу.
-
Простота кодирования — кодирование REST Services и последующая реализация намного проще, чем SOAP. Таким образом, если для веб-сервисов требуется быстрое решение, то REST — это путь.
SOAP следует использовать в следующих случаях
-
Асинхронная обработка и последующий вызов — если существует требование, чтобы клиенту требовался гарантированный уровень надежности и безопасности, тогда новый стандарт SOAP SOAP 1.2 предоставляет множество дополнительных функций, особенно когда речь идет о безопасности.
-
Формальное средство связи — если и клиент, и сервер имеют соглашение о формате обмена, тогда SOAP 1.2 дает жесткие спецификации для этого типа взаимодействия. В качестве примера можно привести сайт онлайн-покупок, на котором пользователи добавляют товары в корзину до совершения платежа. Предположим, у нас есть веб-сервис, который выполняет окончательный расчет. Может быть твердое соглашение о том, что веб-служба будет принимать только наименование корзины, цену за единицу и количество. Если такой сценарий существует, всегда лучше использовать протокол SOAP.
-
Операции с состоянием — если у приложения есть требование о том, что состояние должно поддерживаться от одного запроса к другому, тогда стандарт SOAP 1.2 предоставляет структуру WS * для поддержки таких требований.
Проблемы SOAP и REST API
API известен как интерфейс прикладного программирования и предлагается как клиентом, так и сервером. В мире клиента это предлагается браузером, тогда как в мире серверов это то, что обеспечивается веб-службой, которая может быть либо SOAP, либо REST.
Проблемы с SOAP API
- Файл WSDL. Одной из ключевых задач SOAP API является сам документ WSDL. Документ WSDL сообщает клиенту обо всех операциях, которые может выполнять веб-служба. Документ WSDL будет содержать всю информацию, такую как типы данных, которые используются в сообщениях SOAP, и какие все операции доступны через веб-сервис. Приведенный ниже фрагмент кода является лишь частью примера файла WSDL.
<?xml version="1.0"?>
<definitions name="Tutorial"
targetNamespace=http://demo.guru99.com/Tutorial.wsdl
xmlns:tns=http://demo.guru99.com/Tutorial.wsdl
xmlns:xsd1=http://demo.guru99.com/Tutorial.xsd
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace=http://Demo.guru99.com/Tutorial.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TutorialNameRequest">
<complexType>
<all>
<element name="TutorialName" type="string"/>
</all>
</complexType>
</element>
<element name="TutorialIDRequest">
<complexType>
<all>
<element name="TutorialID" type="number"/>
</all>
</complexType>
</element>
</schema>
</types>
Согласно приведенному выше файлу WSDL, у нас есть элемент с именем «TutorialName», имеющий тип String, который является частью элемента TutorialNameRequest.
Теперь предположим, что если файл WSDL должен был измениться в соответствии с бизнес-требованиями, а TutorialName должно стать TutorialDescription. Это будет означать, что все клиенты, которые в данный момент подключаются к этому веб-сервису, должны будут внести соответствующие изменения в свой код, чтобы учесть изменения в файле WSDL.
Это показывает самую большую проблему файла WSDL, которая заключается в жестком соглашении между клиентом и сервером и то, что одно изменение может оказать большое влияние на клиентские приложения в целом.
- Размер документа. Другой ключевой проблемой является размер сообщений SOAP, которые передаются от клиента к серверу. Из-за больших сообщений использование SOAP в местах, где пропускная способность является ограничением, может быть большой проблемой.
Проблемы с REST API
- Отсутствие безопасности — REST не навязывает никакой безопасности, как SOAP. Вот почему REST очень подходит для общедоступных URL-адресов, но когда дело доходит до передачи конфиденциальных данных между клиентом и сервером, REST является худшим механизмом, который следует использовать для веб-служб.
- Отсутствие состояния. Для большинства веб-приложений требуется механизм отслеживания состояния. Например, если у вас был сайт покупок с механизмом наличия корзины покупок, необходимо знать количество товаров в корзине покупок до того, как будет сделана фактическая покупка. К сожалению, бремя поддержания этого состояния лежит на клиенте, что просто делает клиентское приложение более тяжелым и сложным в обслуживании.
Разница между SOAP и CORBA, DCOM и Java RMI
До появления SOAP и REST такие методы удаленного доступа, как методы RPC (вызовы удаленных процедур), широко использовались. Различные методы удаленного доступа, которые были доступны, упомянуты ниже.
-
CORBA — Это было известно как C ommon O bject R equest B roker A rchitecture. Эта система была создана для того, чтобы приложения, созданные на различных платформах, могли общаться друг с другом. CORBA была основана на объектно-ориентированной архитектуре, но не было необходимости, чтобы вызывающее приложение было основано на этой архитектуре. Основным недостатком этого метода было то, что он должен быть разработан на отдельном языке, называемом языком определения интерфейса, и он просто представлял дополнительный язык, который должен был быть изучен разработчиками для использования системы CORBA.
- DCOM — Это D istributed C omponent O ▪ Таблица M Одел, что фирменная технология Microsoft для клиентов доступа удаленных компонентов. Самая большая проблема с этим механизмом заключалась в том, что клиентское приложение могло освободить ресурсы, когда они больше не нужны.
Во-вторых, когда клиент отправил запрос, клиент должен был убедиться, что запрос был упакован или маршалирован правильно, чтобы веб-служба могла понять отправленный запрос. Другая проблема заключалась в том, что если клиентское приложение представляло собой приложение на основе Java, которое должно было работать с DCOM (технология Microsoft), требовалось дополнительное кодирование, чтобы приложения, созданные на других языках программирования, могли работать с веб-службами на основе DCOM.
-
Java RMI — Известный как Java R EMOTE M енит I nvocation, это реализация Java на том , как удаленные объекты можно назвать с помощью удаленных вызовов процедур. Самым большим ограничением этой технологии было то, что Java RMI мог работать только на виртуальной машине Java. Это означало, что вызывающее приложение также должно быть запущено на платформе Java, чтобы использовать Java RMI.
Основные различия между SOAP и этими методами заключаются в следующем
- Работа по HTTP. У всех методов RPC есть одно большое ограничение: они не работают по протоколу HTTP. Поскольку все приложения в Интернете должны были работать по этому протоколу, это было основным препятствием для клиентов, которые имели доступ к этим веб-службам в стиле RPC.
- Работа с нестандартными портами — поскольку веб-сервисы в стиле RPC не работали по протоколу HTTP, необходимо было открыть отдельные порты, чтобы клиенты могли получить доступ к функциональности этих веб-сервисов.
КЛЮЧЕВАЯ РАЗНИЦА
- SOAP обозначает простой протокол доступа к объектам, тогда как REST обозначает передачу представительного состояния.
- SOAP — это протокол, тогда как REST — это архитектурный паттерн.
- SOAP использует сервисные интерфейсы для предоставления своих функций клиентским приложениям, а REST использует унифицированные локаторы сервисов для доступа к компонентам на аппаратном устройстве.
- SOAP требует большей пропускной способности для его использования, тогда как REST не требует большой пропускной способности.
- SOAP работает только с форматами XML, тогда как REST работает с простым текстом, XML, HTML и JSON.
- SOAP не может использовать REST, тогда как REST может использовать SOAP.