Skip to content

Latest commit

 

History

History
85 lines (55 loc) · 23.6 KB

rest-soap-grpc.md

File metadata and controls

85 lines (55 loc) · 23.6 KB
Raw

REST/SOAP/gRPC

REST (от англ. Representational State Transfer - “передача репрезентативного состояния” или “передача “самоописываемого”состояния”) - архитектурный стиль взаимодействия компонентов распределенного приложения в сети. Другими словами, REST - это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной гипермедиа-системы. В определенных случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.

В сети Интернет вызов удаленной процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса. Для веб-служб, построенных с учетом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.

Требования к архитектуре REST

Существует шесть обязательных ограничений для построения распределенных REST-приложений по Филдингу.

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

Обязательными условиями-ограничениями являются:

  • Модель клиент-сервер: Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.
  • Отсутствие состояния: Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится (Stateless protocol или «протокол без сохранения состояния»). Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние. Во время обработки клиентских запросов считается, что клиент находится в переходном состоянии. Каждое отдельное состояние приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.
  • Кэширование: Как и во Всемирной паутине, клиенты, а также промежуточные узлы, могут выполнять кэширование ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно частично или полностью устранить некоторые клиент-серверные взаимодействия, еще больше повышая производительность и масштабируемость системы.
  • Единообразие интерфейса: Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо. К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия:
    • Идентификация ресурсов: Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.
    • Манипуляция ресурсами через представление: Если клиент хранит представление ресурса, включая метаданные - он обладает достаточной информацией для модификации или удаления ресурса.
    • «Самоописываемые» сообщения: Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру, обработчик сообщения (parser), необходимый для извлечения данных, может быть указан в списке MIME-типов.
    • Гипермедиа как средство изменения состояния приложения (HATEOAS): Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, Web Linking (RFC 5988 -> RFC 8288) и JSON Hypermedia API Language являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.
  • Слои: Клиент обычно не способен точно определить, взаимодействует он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счет балансировки нагрузки и распределенного кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации.
  • Код по требованию (необязательное ограничение): REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или скриптов. Филдинг утверждает, что дополнительное ограничение позволяет проектировать архитектуру, поддерживающую желаемую функциональность в общем случае, но, возможно, за исключением некоторых контекстов.

Просто посмотреть как выглядят запросы-ответы можно во вкладке Network в DevTools. Попробовать отправить запрос и посмотреть ответ можно с помощью этой статьи.

SOAP

SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам) - протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP.

SOAP является расширением протокола XML-RPC. SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Структура протокола:

  • Envelope - корневой элемент, который определяет сообщение и пространство имен, использованное в документе;
  • Header - содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации;
  • Body - содержит сообщение, которым обмениваются приложения;
  • Fault - необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.

Пример SOAP-запроса на сервер интернет-магазина

WSDL - это описательный язык, основанный на языке разметки XML, и именно в wsdl описан веб-сервис, который вам придется тестировать. WSDL включает в себя информацию о местоположении сервиса, часто включает в себя XSD. Именно из WSDL SOAPUI генерирует проверяемые классы.

XSD - это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных.

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

Что тестируется в SOAP? Бизнес-логика и то, что схема валидируется сервером (а также, что она принимает на вход параметры правильного формата). Собственно все, что касается схемы, проверяется на этапе разработки, а после, только бизнес-логика (до того момента, пока опять не начнутся изменения в схеме).

Отличия REST и SOAP

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

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

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило - в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы - PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

gRPC

Для тех, кто еще не слышал о gRPC, gRPC - это не зависящий от языка фреймворк для удаленного вызова процедур (RPC, remote procedure calls), разработанный Google, которая серьезно вкладывается в производительность и масштабирование. Он появился довольно давно, но многие (а, может быть, только я) отложили его на второй план из-за затрат на написание IDL и дополнительного кода стабов (stub), который тоже необходимо поддерживать. В то же время REST очень легко реализуется с помощью ASP.NET Core WebAPI.

Аналогично использованию JSON для REST, для gRPC используется Protocol Buffers - не зависящий от языка формат для сериализации структурированных данных. Этим gRPC отличается от REST. Поддержка Protocol Buffers есть для всех основных языков благодаря компилятору protoc, который генерирует необходимый исходный код классов из определений в proto-файле. Еще важный момент состоит в том, что для связи gRPC использует HTTP/2, а это приносит дополнительные преимущества, такие как сжатие HTTP-заголовков и мультиплексирование запросов.

Источники:

Доп. материал: