Вопросы проектирования архитектуры современных веб-сервисов: чем отличается архитектурный стиль REST от RPC-подходов (SOAP API, GraphQL API и gRPC API).
REST vs RPC API
Для API современных веб-приложений можно выделить 2 основных подхода к дизайну архитектуры: REST и RPC, к которому относятся SOAP API, GraphQL API и gRPC API. Основная разница между ними в том, что REST (Representational State Transfer) – это архитектурный стиль, основанный на концепции ресурсов, каждый из которых имеет свой уникальный URI (Uniform Resource Identifier), куда отправляются различные HTTP-запросы для взаимодействия с веб-сервисом. REST API позиционируется как stateless-сервис, где сервер не сохраняет состояние между запросами клиента и для ответа на каждый клиентский запрос тот должен включать всю необходимую информацию для его обработки. Сервер не сохраняет сессию между запросами. Такая архитектура довольно легко реализуется сочетанием конечных точек – т.е. ресурсов и стандартных HTTP-методов (GET, POST, PUT, DELETE) для обращения к ним, отлично подходит для простых CRUD-операций, но для сложных транзакционных систем требует дополнительных решений. Пример проектирования и реализации такого веб-сервиса я показывала здесь и здесь.
RPC (Remote Procedure Call) — подход к взаимодействию между системами, когда клиент вызывает удаленные процедуры или функции на сервере так, будто они локальные. Клиент вызывает метод на сервере, передавая необходимые параметры, и ожидает результат выполнения этой процедуры. Основная идея RPC заключается в имитации локальных вызовов функций, но на удалённом сервере. RPC основан на функциях, а не на ресурсах. Этот стиль реализуют следующие подходы к дизайну API веб-приложений:
- SOAP API – API, основанный на строгом протоколе обмена XML-сообщениями SOAP (Simple Object Access Protocol), который использует стандарты веб-служб (WS, Web Services) для обеспечения безопасности, надежности и транзакционной целостности приложений. Это подходит для систем, требующих высокой надежности, безопасности и сложных транзакций. Пример реализации такого веб-сервиса я показывала здесь.
- gRPC API – API, основанный на gRPC (Remote Procedure Calls), открытом фреймворке от Google для высокопроизводительных приложений, использующий протокол HTTP/2 и бинарный формат protobuf для передачи данных со строгой встроенной схемой. Он поддерживает не только взаимодействие в стиле запрос-ответ, но и потоковую передачу, в т.ч. двунаправленную. Подходит для микросервисной архитектуры и систем, требующих высокой производительности и низкой задержки. Пример проектирования и реализации такого веб-сервиса я показывала здесь и здесь.
- GraphQL API – API, использующий GraphQL (Graph Query Language), язык запросов, позволяющий клиентам запрашивать именно те данные, которые им необходимы, указывая в полезной нагрузке POST-запросов HTTP функции с GraphQL-запросами на чтение, мутациями на изменение данных или долговременные подписки. Благодаря тому, что клиент сам может определять структуру ответа сервера, снижается количество запросов и сетевой трафик. Это подходит для приложений с высокой изменчивостью данных и необходимостью снизить количество запросов между клиентом и сервером. Примеры GraphQL-запросов я показывала здесь.
REST не является специфической реализацией RPC, а представляет собой отдельный архитектурный стиль, основанный на манипуляции ресурсами через стандартные HTTP-методы. А RPC-подходы фокусируются на выполнении конкретных удалённых процедур или функций. Поэтому RPC API больше раскрывает клиенту детали внутреннего устройства серверного приложения через конкретные методы и их параметры. REST API абстрагирует детали реализации, предоставляя клиенту стабильные и предсказуемые конечные точки для взаимодействия с сервером.
Резюмируем отличия в таблице.
| Характеристика | REST API | SOAP API | GraphQL API | gRPC API |
| Основная концепция | Ресурсы и HTTP-методы доступа к ним | Удаленные функции | Удаленные функции | Удаленные функции |
| Протокол | HTTP | SOAP поверх HTTP или других протоколов прикладного уровня, например, SMTP | HTTP | HTTP/2 |
| Формат сообщений | Любой (JSON, XML, TXT, HTML и пр.) | XML | JSON | protobuf |
| Типизация (схема) сообщений | Изначально отсутствует | Строгая | Строгая | Строгая |
| Типовой характер взаимодействия | В основном синхронный запрос-ответ | В основном синхронный запрос-ответ, но также поддерживает и асинхронные вызовы | Синхронный запрос-ответ на чтение данных (query) и их изменение (mutation), подписки на изменения данных в реальном времени (subscription) | Запрос-ответ, потоковая передача, в т.ч. двусторонняя |
| Транзакционность | Слабая. Для атомарности и целостности сложных транзакций нужна реализация дополнительных механизмов | Отличная. Поддержка стандарта WS-Transaction позволяет управлять распределенными транзакциями, обеспечивая полное соответствие ACID-требованиям | Неплохая. Обычно отдельные мутации выполняются атомарно, обеспечивая базовую целостность данных. Для транзакционной целостности нескольких связанных операций нужны дополнительные механизмы | Хорошая. Сам по себе gRPC не имеет встроенных механизмов для управления транзакциями, но может интегрироваться с транзакционными системами и библиотеками |
| Область применения | Публичные API, простые сервисы с CRUD-операциями | Системы, требующие высокой надежности, безопасности и сложных транзакций | Сервисы с высокой изменчивостью данных, где нужно сократить количество запросов между клиентом и сервером | Системы с микросервисной архитектурой, требующие высокой производительности и низкой задержки |
| Раскрытие информации клиенту о внутреннем устройстве сервера | Нет. Использование ресурсах и стандартных HTTP-методов для выполнения операций над ними позволяет абстрагировать внутреннюю структуру сервера, предоставляя единый и предсказуемый интерфейс для взаимодействия. Клиенты взаимодействуют с ресурсами через их уникальные URL без знания, как эти ресурсы реализованы на сервере | Да. Использование строго определённых контрактов через WSDL (Web Services Description Language), которые описывают доступные методы и их параметры раскрывает клиенту внутренние функции сервера | Частично. Раскрывает схему данных и может косвенно предоставлять информацию о структуре данных и доступных над ними операциях | Да. Описание функций сервиса, а также структуры данных их входных параметров и результатов в proto-файлах используется для кодогенерации серверной и клиентской частейю Поскольку код клиента основан на proto-определении, он знает о конкретных методах сервера и их параметрах |
Таким образом, каждый подход имеет свои особенности, которые обусловливают его область применения. Выбор зависит от требований, внешних и внутренних ограничений, а также возможностей команды разработки. Как сделать проектирование дизайна API с учетом этих факторов, рассмотрим на практическом примере в следующий раз.
Подробнее познакомиться со всеми рассмотренными темами, а также другими основами архитектуры и интеграции информационных систем вы сможете на курсах Школы прикладного бизнес-анализа и проектирования информационных систем в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
