REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API

REST SOAP gRPC GraphQL примеры курсы обучение, интеграция информационных систем REST SOAP gRPC GraphQL простыми словами для начинающих примеры курсы обучение, интеграция информационных систем простыми словами для начинающих примеры курсы обучение, основы интеграции информационных систем для бизнес-аналитика, интеграция информационных систем основы введение, краткий ликбез по интеграции информационных систем, обучение системных и бизнес-аналитиков, курсы системного и бизнес-анализа, Школа прикладного бизнес-анализа Учебный Центр Коммерсант

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

Как устроен REST API и при чем здесь GraphQL

Как я уже отмечала ранее, интеграцию информационных систем по API можно рассматривать как взаимодействие типа «запрос-ответ» к одной или нескольким конечным точкам (endpoint), которые реализуют возможности доступа к данным и манипулирование ими по заранее определенному шаблону запроса и ответа. Конечная точка – это адрес ресурса, который является пунктом доступа к системе извне. Endpoint представляет собой путь доступа к ресурсу и является его URL-адресом. Например, в публичном API с картинками про котиков для каждого HTTP-кода одна из конечных точек выглядит так: https://http.cat/404. Этот HTTP-запрос возвращает картинку со спрятавшимся котиком, иллюстрируя идею страницы, не найденной на сервере, что кодируется ошибкой с номером 404.

В зависимости от стиля шлюза межсистемной интеграции, т.е. программного интерфейса приложения (API, Application Programming Interface) система предоставляет одну или несколько конечных точек, чтобы другие приложения могли получить доступ к ее данным или функциональным возможностям. В частности, популярный клиент-серверный стиль архитектуры REST (Representational State Transfer), предложенный Роем Филдингом, одним из авторов HTTP-протокола, в его докторской диссертации в 2000 году, предполагает множество конечных точек, каждая из которых предоставляет доступ к отдельному ресурсу.

Клиенты отправляют HTTP-запросы серверу, обращаясь к конечным точкам, которые предоставляют ресурсы. Например, GET-запрос к URL-адресу http://site-domain-name/products/12345 вернет данные о товаре с идентификатором 12345. А GET-запрос к URL-адресу http://site-domain-name/clients/987 вернет данные о клиенте с идентификатором 987. REST может возвращать данные в любом формате (HTML, XML, JSON), но чаще всего это человеко-читаемый текстовый формат JSON (JavaScript Object Notation) на основе JavaScript. В рассмотренных примерах указано 2 конечные точки, которые используются для обращения к разным ресурсам:

  • /products – используется для обращения к товарам;
  • /clients – используется для обращения к клиентам.

Помимо GET-запросов, которые нужны для получения информации о ресурсе, в REST используются и другие HTTP-методы для запроса данных, прямо указывающие, что нужно сделать с ресурсов. Например, POST используется для создания нового экземпляра ресурса, PUT – для полного обновления экземпляра ресурса, PATCH – для его частичного обновления, а DELETE – для удаления. Говоря про эти HTTP-методы, следует отметить их отношение к идемпотентности возвращаемых результатов. Идемпотентность функции означает, что результат, возвращенный ей в первый раз, будет таким же при повторных обращениях.

Поскольку GET-запрос используется для чтения данных, он является безопасным и идемпотентным. Применяемый для создания новых ресурсов POST-запрос считается небезопасным и не идемпотентным. Например, отправив POST-запрос на конечную точку http://site-domain-name/clients 34 раза, мы создадим 34 новых клиента, каждый из которых будет иметь свой идентификатор, т.е. результаты выполнения запроса каждый раз будут разные.

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

Наконец, HTTP-запрос DELETE является небезопасным, но идемпотентным, т.к. он предполагает удаление конкретного ресурса. Например, DELETE-запрос, отправленный на конечную точку http://site-domain-name/products/12345 удалит товар с ID=12345, вернув успешный код HTTP-ответа 200. При повторной отправке этого же DELETE-запроса к этой же конечной точке HTTP-код ответа будет 404, т.к. ресурс уже удален, т.е. он не существует и не может быть найден. Хотя формально разные ответы и нарушают принцип идемпотентности, но это допустимое расширение данного правила, т.к. все последующие результаты, кроме 1-го, будут одинаковыми.

HTTP-метод Назначение Идемпотентность Безопасность
GET Получить сведения о ресурсе (прочитать данные) Да Да
POST Создать новый ресурс Нет Нет
PUT Полностью обновить ресурс Да Нет
PATCH Частично обновить ресурс Может быть да, может быть нет Нет
DELETE Удалить ресурс Почти да (все, кроме 1-го вызова) Нет

В заключение ликбеза про REST API отмечу, что он является stateless, т.е. сервер не сохраняет состояние клиента, но клиент может кэшировать данные, полученные с сервера, чтобы сократить нагрузку на сеть и повысить производительность. Благодаря отсутствию состояния нет необходимость держать длительное соединение клиента с сервером, что снижает нагрузку на сеть и на сервер. Клиенты сообщают серверу состояние приложения через заголовок, тело и параметры в каждом HTTP-запросе к ресурсу по URL-адресу. Это соответствует REST-ограничению HATEOAS (Hypermedia as the Engine of Application State).

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

Хотя REST основан на ресурсах, они отделены от представлений, возвращаемых клиенту: в ответ на запрос сервер возвращает клиенту не базу данных, а HTML/XML или JSON-сообщения, представляющий отдельные записи в ней и результаты манипуляций над ними. Все сообщения являются самодокументируемыми, т.е. они содержат достаточно данных, чтобы его выполнить. Операции над ресурсами реализуются через представления, т.е. обладая правами на выполнение конкретных CRUD-операций над объектами базы данных, пользователь может манипулировать ресурсами на сервере. Подробнее о запросах и ответах HTTP в системе с REST API читайте в моей новой статье.

Основы архитектуры и интеграции информационных систем

Код курса
OAIS
Ближайшая дата курса
22 декабря, 2022
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.

Архитектурный стиль REST сегодня активно используется в большинстве веб-приложений, но из-за множества конечных точек, каждая из которых предназначена для отдельного ресурса, он увеличивает нагрузку на сеть. Поэтому в 2012 году был предложен стиль межсистемной интеграции по API под названием GraphQL, который сокращает нагрузку на сеть, позволяя клиенту указывать, какие данные ему нужны через обращение к одной конечной точке. Она позволяет получать доступ к другим связанным ресурсам через вход в ресурс, если эта взаимосвязь между ресурсами заранее определена в схеме данных. Являясь декларативным языком запросов для API со встроенной проверкой типов данных и серверной средой выполнения, GraphQL возвращает сложный граф данных (отсюда и слово Graph в названии), уменьшая количество запросов по сети до одного показа. CRUD-операции над данными в GraphQL реализуются через разные виды POST-запросов: простые запросы (query) аналогичны GET в REST, а за изменение данных отвечают запросы-мутации (mutation), позволяя создавать, обновлять и удалять данные на сервере.

Недостатками GraphQL считаются сложность реализации, статичная схема данных, отсутствие кэширования и трудности в управлении версиями. Однако, этот API хорошо подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно реализовать единообразие в средствах выполнения запросов, уменьшить число конечных точек и снизить нагрузку на сеть.

Удаленный вызов процедур: SOAP и gRPC

При том, что REST часто сравнивают с SOAP, у них практически нет ничего общего, кроме, пожалуй, даты возникновения. SOAP (Simple Object Access Protocol), простой протокол доступа к объектам, был предложен корпорацией Microsoft всего 2-мя годами раньше REST. А благодаря мощной корпоративной поддержке в рамках продвижения платформы .NET, SOAP широко распространился в различных системах enterprise-класса как средство межсистемной интеграции. В отличие от REST, он работает по принципу удаленного вызова процедур (PRC, Remote Procedure Call), когда через POST-запрос к 1-ой конечной точке клиент вызывает на сервере функцию, специфицированную в теле XML-сообщения.

Хотя SOAP может работать с любым протоколом прикладного уровня (SMTP, FTP, HTTP, HTTPS), чаще всего он используется поверх HTTP. В качестве формата представления данных SOAP использует только язык разметки XML. Благодаря наличию строгой схемы данных (XSD) и встроенной обработке ошибок SOAP до сих пор активно используется во многих корпоративных сервисах, особенно связанных с финансами. Но из-за тяжеловесности XML-формата и правил формирования XML-сообщений, можно сказать, что SOAP сегодня теряет популярность и, в основном, применяется в так называемых legacy-системах, которые первоначально были разработаны в конце 90-хх гг.

Впрочем, сегодня RPC как технология межсистемной интеграции переживает второе рождение. Впервые возникнув в 80-х гг. XX века, она легла в основу SOAP, а в 2015 году была переосмыслена корпорацией Google под названием gRPC. Поскольку приложения Google обрабатывают огромные объемы данных, тяжеловесный XML в SOAP и избыточная нагрузка на сеть в REST привели к необходимости создания нового интеграционного API. gRPC устраняет эти недостатки, используя для запросов и ответов легковесный бинарный формат protobuf. Он не является человеко-читаемым, но зато дает высокую производительность и низкую нагрузку на сеть. Поэтому неслучайно gRPC используется в высоконагруженных системах, где нужна высокая пропускная способность и производительность при низких требованиях к сети, а также аппаратным ресурсам сервера и клиента, например, платформы интернета вещей.

Как и  SOAP, gRPC тоже использует только POST-запросы для обращения к одному endpoint’у как единственной точке входа в приложение. gRPC имеет строгую спецификацию типов данных и разные типы методов обслуживания, а также позволяет удерживать длительные потоки связи между клиентом и сервером в режиме реального времени. Клиентское приложение может напрямую вызывать метод на сервере аналогично обращению к локальному объекту, что упрощает разработку распределенных систем. gRPC определяет методы, доступные для удаленного вызова, включая параметры и типы возвращаемых данных. Сервер реализует этот интерфейс и использует его для обработки клиентских вызовов. Клиентское приложение предоставляет методы, такие же, как сервер. При этом клиентские и серверные части могут работать в различных средах и часто бывают написаны на разных языках программирования, которые поддерживают gRPC: C#, C++, Go Java, Kotlin, Objective-C, PHP, Python, Ruby и др.

Таким образом, каждый стиль межсистемной интеграции по API имеет свои достоинства и недостатки, обусловливающие особенности его практического применения. Выбор между REST, SOAP, gRPC или GraphQL делает ИТ-архитектор на основании функциональных и нефункциональных требований, которые разрабатывает аналитик и специфицирует в виде ТЗ или SRS. А как аналитик может помочь архитектору сделать этот выбор, определив ключевые требования, читайте в моей новой статье.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
1 февраля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.

Краткое сравнение рассмотренных API-стилей интеграции показано в следующей таблице.

интеграция информационных систем API, REST SOAP GraphQL gRPC
Сравнение API межсистемной интеграции: REST vs SOAP vs GraphQL vs gRPC

Проверить, как вы усвоили материал этой статьи, вам поможет наш интерактивный открытый тест.

API межсистемной интеграции: тест для аналитика

А подробнее познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://restapitutorial.ru/lessons/whatisrest.html
  2. https://xml.readthedocs.io/index.html
  3. https://graphql.org/learn/
  4. https://grpc.io/docs/

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!