Редкое собеседование на позицию системного аналитика обходится без вопросов про разницу между 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
Ближайшая дата курса
5 ноября, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Архитектурный стиль REST сегодня активно используется в большинстве веб-приложений, но из-за множества конечных точек, каждая из которых предназначена для отдельного ресурса, он увеличивает нагрузку на сеть. Поэтому в 2012 году был предложен стиль межсистемной интеграции по API под названием GraphQL, который сокращает нагрузку на сеть, позволяя клиенту указывать, какие данные ему нужны через обращение к одной конечной точке. Она позволяет получать доступ к другим связанным ресурсам через вход в ресурс, если эта взаимосвязь между ресурсами заранее определена в схеме данных. Являясь декларативным языком запросов для API со встроенной проверкой типов данных и серверной средой выполнения, GraphQL возвращает сложный граф данных (отсюда и слово Graph в названии), уменьшая количество запросов по сети до одного показа. CRUD-операции над данными в GraphQL реализуются через разные виды POST-запросов: простые запросы (query) аналогичны GET в REST, а за изменение данных отвечают запросы-мутации (mutation), позволяя создавать, обновлять и удалять данные на сервере.
Недостатками GraphQL считаются сложность реализации, статичная схема данных, отсутствие кэширования и трудности в управлении версиями. Однако, этот API хорошо подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно реализовать единообразие в средствах выполнения запросов, уменьшить число конечных точек и снизить нагрузку на сеть. Подробнее про GraphQL с практическими примерами запросов читайте в новой статье.
Удаленный вызов процедур: 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-хх гг. Подробнее о том, как устроена межсистемная интеграция с веб-сервисами по SOAP, читайте в моей новой статье.
Впрочем, сегодня 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
Ближайшая дата курса
2 декабря, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Краткое сравнение рассмотренных API-стилей интеграции показано в следующей таблице.
Проверить, как вы усвоили материал этой статьи, вам поможет наш интерактивный открытый тест.
А подробнее познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
Источники
