Выбор архитектуры API — одна из типичных задач, с которыми сталкивается бэкенд‑разработчик. Если ошибиться на старте, можно столкнуться с проблемами при масштабировании: например, мобильному приложению придется постоянно скачивать лишние мегабайты данных, а микросервисам — тратить время на обработку тяжелых ответов. Чтобы этого избежать, важно заранее разобраться в особенностях разных подходов. И в этой статье мы сравним три популярные технологии обмена данными: REST, GraphQL и gRPC.
Материал рассчитан на новичков, поэтому сложных терминов в нем не будет. Мы разберем работу каждой технологии на примере ресторанной кухни, а также покажем, как протестировать их в реальных сервисах — без громоздкого кода.
REST — для работы с типовыми ресурсами
REST — это архитектурный стиль создания API, в котором данные представлены в виде ресурсов. Под ресурсами здесь понимаются отдельные сущности, например пользователи, товары или заказы, — то есть все, что можно представить как карточку в системе. Клиент обращается к серверу, чтобы получить нужный ресурс, создать новый, изменить текущий или удалить его.
Как правило, у каждого типа ресурсов есть собственный URL-адрес — эндпоинт. Например, /users отвечает за пользователей, а /orders — за заказы. А вот действие, которое сервер должен выполнить с ресурсом, задается с помощью HTTP-метода. Так, с помощью запроса GET /users/42 вы сможете получить данные пользователя с идентификатором 42, запрос POST /orders сформирует новый заказ, а DELETE /posts/7 удалит публикацию с идентификатором 7.
Представьте стандартное ресторанное меню, где у каждого блюда заранее определены состав и подача. Гость делает заказ, официант передает его на кухню и приносит блюдо. Точно так же работает REST: клиент выбирает ресурс по его адресу и отправляет запрос серверу, а сервер выполняет действие и возвращает результат. Меню здесь можно сравнить с набором эндпоинтов, заказ — с HTTP‑запросом, кухню — с сервером, а готовое блюдо — с ответом. При этом клиент получает ресурс именно в том формате, который заранее задал сервер.
Такой подход удобен, когда данные имеют понятную структуру, а клиент заранее знает, какой ответ получит. Поэтому REST часто используют для работы с каталогами товаров, профилями пользователей, заказами, публикациями, комментариями, заявками, бронированиями и другими типовыми ресурсами.
Однако у предсказуемости есть обратная сторона. Допустим, приложению нужен только адрес электронной почты пользователя, а сервер вместе с ним возвращает имя, телефон, адрес и сведения о компании. Бывает и наоборот: чтобы показать профиль пользователя вместе с публикациями и комментариями, приложению приходится обращаться к нескольким эндпоинтам.
Конечно, разработчики могут решить эти проблемы с помощью фильтров, параметров и дополнительных эндпоинтов. Но если требования к составу данных часто меняются, REST API постепенно усложняется — в такой ситуации лучше рассмотреть другие подходы.
Чтобы попробовать REST на практике, вы можете установить настольную версию Postman — программу для отправки запросов к API. В качестве сервера подойдет бесплатный сервис JSONPlaceholder, который будет имитировать REST API с тестовыми данными: пользователями, постами и комментариями.
Откройте Postman, создайте в нем новый HTTP‑запрос и выберите метод GET, который сообщает серверу, что мы хотим получить данные. В адресную строку вставьте https://jsonplaceholder.typicode.com/users/1 и нажмите кнопку Send. После этого Postman отправит запрос к ресурсу /users/1, а в нижней части окна покажет ответ в формате JSON с различными данными пользователя.
GraphQL — для приложений с гибкими запросами данных
Если в REST-архитектуре состав ответа, как правило, заранее определяет сервер, то GraphQL работает иначе. Это язык запросов к API и среда их выполнения, с помощью которых клиент самостоятельно перечисляет нужные поля. Чаще всего все запросы отправляются в единую точку входа, например /graphql, а доступные типы данных и связи между ними описываются в строгой схеме.
Давайте продолжим аналогию с рестораном, только теперь вместо стандартного фиксированного меню вы можете воспользоваться конструктором блюд. То есть вы можете сказать повару: «Соберите салат из креветок и огурцов, добавьте оливковое масло, но не кладите помидоры и лук». После этого повар отдаст ровно то, что вы перечислили в заказе. Так же работает GraphQL: клиент указывает нужные поля и связанные объекты, а сервер собирает их в один ответ.
GraphQL часто выбирают для создания мобильных приложений и сложных интерфейсов, где каждому экрану нужен свой набор данных. Например, в интернет‑магазине каталогу достаточно названия, цены и изображения товара, а карточке товара дополнительно нужны еще описание, характеристики, продавец и отзывы. В REST для таких сценариев разработчикам приходится заводить отдельные эндпоинты, делать несколько запросов или получать лишние поля. В GraphQL все запросы идут в одну точку входа, а клиент запрашивает только нужные поля. За счет этого интерфейс можно перерисовывать намного быстрее и обходиться без постоянного добавления новых эндпоинтов на бэкенде.
Однако та гибкость, которую получает фронтенд, усложняет работу бэкенда: серверу нужно валидировать запрос, проверить права доступа, собрать данные из разных источников и сформировать ответ. Если запросы будут слишком глубокими или тяжелыми, они могут создавать высокую нагрузку, а неаккуратная работа со связанными данными — привести к проблеме N+1, когда вместо одного обращения к базе выполняется множество дополнительных.
Чтобы попробовать GraphQL на практике, откройте публичный Countries GraphQL API. В левой части страницы находится редактор запросов, а в правой отображается ответ сервера. Вставьте в редактор следующий простой запрос:
query {
country(code: "RU") {
name
native
capital
emoji
}
}
После запуска сервер вернет JSON только с четырьмя запрошенными полями:
{
"data": {
"country": {
"native": "Россия",
"capital": "Moscow",
"name": "Russia"
}
}
}
Теперь удалите из запроса строку capital и запустите его еще раз — поля со столицей в новом ответе не будет. Также вы можете по очереди убрать name, native или emoji либо запросить другие поля из схемы API: например, код страны (code), валюту (currency) или телефонный код (phone). Сервер каждый раз будет возвращать только то, что вы указали. И это наглядно показывает главное отличие GraphQL от REST: клиент самостоятельно определяет состав данных.
gRPC — для взаимодействия между микросервисами
Если REST и GraphQL в первую очередь применяют для обмена данными между клиентом и сервером, то gRPC решает другую задачу: он предназначен для взаимодействия внутренних сервисов. Это фреймворк удаленного вызова процедур, где один сервис вызывает метод другого почти так же, как обычную функцию в коде. Но на самом деле это сетевой запрос, в котором название метода, параметры и формат ответа заранее фиксируются в общем контракте.
Для примера возьмем онлайн-банк с двумя сервисами: один обрабатывает переводы, а другой выявляет подозрительные транзакции. Перед переводом первый сервис вызывает у второго метод CheckTransaction и передает ему сумму, отправителя и получателя для проверки. Чтобы оба сервиса одинаково понимали этот вызов, разработчики заранее описывают доступные методы, параметры и структуру сообщений в специальном файле .proto. Затем на основе этого файла gRPC создает клиентский и серверный код, а сами сообщения кодируются в компактном формате Protocol Buffers и передаются по HTTP/2.
С метафорой здесь немного сложнее, чем у нас было с REST и GraphQL. Представьте кухню будущего, где вместо людей готовят роботы и напрямую обмениваются командами. Например, робот‑повар может вызывать у робота‑кладовщика операцию ReserveIngredients и передавать список и количество продуктов. Кладовщик сразу понимает, что ему сделать и какой ответ вернуть, поскольку все операции заранее описаны в общей инструкции. В этой аналогии роботы — отдельные сервисы, операция — метод gRPC, инструкция — контракт в файле .proto, а короткие команды — сообщения Protocol Buffers.
Такой подход хорошо подходит для микросервисов, которые часто обмениваются данными и должны придерживаться фиксированного формата сообщений. Кроме того, gRPC поддерживает потоковую передачу данных. Например, сервис мониторинга может получать актуальные показатели температуры серверов, а приложение доставки — координаты курьера. Новые значения поступают по мере появления, поэтому для каждого обновления не нужен отдельный запрос.
Однако подключиться к gRPC API сложнее, чем к REST или GraphQL. Обычный браузер не умеет отправлять такие запросы, и для этого ему необходимы gRPC‑Web и дополнительный сервер‑посредник. Кроме того, разработчику понадобится файл .proto с описанием методов и специальная программа для отправки запросов. Поэтому технологию gRPC чаще используют внутри системы, а для публичных API выбирают более доступные REST или GraphQL.
Чтобы настроить gRPC, обычно необходимо запустить сервер, подготовить файл .proto и сгенерировать рабочий код. Для первого знакомства это может быть довольно сложно, поэтому мы сделаем простой gRPC‑вызов через Postman и публичный сервер Postman Echo. Нажмите New, выберите gRPC и укажите адрес grpc.postman-echo.com. После этого программа загрузит список доступных методов — выберите SayHello. Затем перейдите в блок Message, нажмите Use Example Message и подставьте вместо примера свое имя:
{
"greeting": "Анастасия"
}
Когда вы нажмете кнопку Invoke, Postman отправит сообщение на сервер Postman Echo и сразу вызовет метод SayHello. Сервер выполнит этот метод и вернет приветствие в поле reply. Postman покажет ответ в читаемом виде, хотя по сети запрос и ответ передаются как бинарные сообщения Protocol Buffers.
Какой подход выбрать для своего проекта
Вы, вероятно, уже поняли, что универсального подхода к построению API нет: выбор зависит от устройства проекта, типа клиентов, структуры данных и требований к производительности. Для небольшого сервиса с понятным набором ресурсов мы рекомендуем REST — его относительно легко реализовать, тестировать и поддерживать. GraphQL подойдет, если разным интерфейсам регулярно нужны разные наборы данных, а gRPC — когда важны быстрый и эффективный обмен между внутренними сервисами или потоковая передача.
Если вы занимаетесь бэкендом и хотите сравнить подходы на более техническом уровне, посмотрите таблицу. В ней мы собрали основные характеристики REST, GraphQL и gRPC: как устроено взаимодействие, в каком формате передаются данные, как описывается контракт, есть ли потоковая передача и многое другое. Пройдясь по всем параметрам, вы сможете быстро сопоставить возможности каждого подхода с требованиями проекта и подобрать оптимальный вариант.
| Параметр | REST | GraphQL | gRPC |
| Принцип взаимодействия | Ресурсы и HTTP-методы | Запрос полей по схеме | Вызов удаленных методов |
| Формат и передача данных | Чаще JSON по HTTP | Чаще JSON по HTTP | Protocol Buffers по HTTP/2 |
| Контракт API | OpenAPI — необязательно | GraphQL-схема | Файлы .proto |
| Состав ответа | Определяет сервер | Выбирает клиент | Фиксирует контракт |
| Кэширование | HTTP-кэш и CDN | Требует настройки | На уровне приложения |
| Потоковая передача | Через SSE или WebSocket | Через подписки: сервер автоматически отправляет клиенту обновления сразу после их появления | Встроена: поток может передаваться от клиента к серверу, от сервера к клиенту или в обе стороны одновременно |
| Работа в браузере | Напрямую | Напрямую | Через gRPC-Web или прокси |
| Основные сценарии | Публичные API, интеграции, типовые ресурсы | Мобильные приложения, сложные интерфейсы | Микросервисы, потоковая передача |
Полезные статьи и ссылки по теме
- Основные принципы архитектурного стиля REST
- Официальная документация по GraphQL
- Введение в gRPC: основные принципы и устройство
- Backend-разработчик: кто это такой и чем занимается
- Чем frontend отличается от backend’а? Объясняем на мемах
- Что нужно знать, чтобы сейчас начать работать backend-разработчиком
