REST или GraphQL: под какие задачи выбрать каждый подход

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

Сначала разделите задачу и протокол

REST — не формат JSON и не конкретный набор URL. Это архитектурный стиль, который обычно реализуют поверх HTTP. Его сильная сторона — использование привычных механизмов HTTP: методов, кодов ответа, заголовков, кешей, прокси и инструментов наблюдаемости.

GraphQL — язык запросов и система выполнения запросов к типизированной схеме. Клиент указывает, какие поля ему нужны, а сервер возвращает структуру, соответствующую этому запросу. GraphQL часто работает поверх HTTP, но сама спецификация не превращает HTTP в обязательную часть модели.

В статье под GraphQL имеется в виду спецификация GraphQL October 2021, а под REST — API, использующий HTTP по правилам RFC 9110. Конкретные библиотеки, шлюзы и генераторы клиентов могут добавлять собственные ограничения.

Выбирайте не между «современным» и «простым», а между двумя способами распределить сложность: REST оставляет больше решений клиенту, GraphQL — серверу и платформенной команде.

Сноска. Over-fetching — получение лишних полей, которые клиенту не нужны. Under-fetching — ситуация, когда одного ответа недостаточно и приходится делать дополнительные запросы.

Когда REST подходит лучше

Стабильные ресурсы и обычные операции

REST хорошо работает, когда предметная область естественно раскладывается на ресурсы: заказ, пользователь, документ, платеж, комментарий. Клиент получает ресурс по адресу, создаёт или меняет его стандартными HTTP-операциями, а сервер возвращает понятный статус.

Такой вариант особенно удобен для внутренних сервисов, партнёрских интеграций и публичного API, где важны предсказуемость и независимость клиентов от внутренней схемы базы данных. Для типичных операций чтения и изменения сущностей REST редко требует отдельного языка запросов.

Кеширование и инфраструктура важнее гибкости ответа

REST проще встроить в существующую инфраструктуру. Кеширование можно строить вокруг URL и HTTP-заголовков, а права — вокруг ресурсов и операций. CDN, reverse proxy, логи и системы мониторинга обычно уже умеют показывать, какой URL, метод и статус вызываются.

Это не означает, что REST автоматически кешируется. Сервер всё равно должен корректно задавать заголовки кеширования, учитывать авторизацию и инвалидировать данные. Но модель ресурсов даёт инфраструктуре понятную точку приложения.

Команда хочет простую границу ответственности

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

Когда GraphQL оправдан

Один экран собирает данные из нескольких доменов

GraphQL полезен для интерфейсов, где один экран показывает, например, профиль, последние заказы, рекомендации и уведомления. В REST клиенту может понадобиться несколько запросов, а часть данных окажется лишней для конкретного устройства. В GraphQL клиент описывает дерево нужных полей, а сервер собирает результат из резолверов или других источников.

Выигрыш появляется не от самого слова GraphQL, а от хорошо спроектированной схемы и серверного слоя, который умеет получать данные без каскада медленных обращений.

Клиентов много, а набор полей меняется часто

Веб, iOS, Android и телевизионное приложение могут показывать один объект с разным уровнем детализации. REST решает это через отдельные представления, параметры, версии и специализированные endpoints. GraphQL даёт клиентам один контракт и возможность запрашивать подмножество полей.

Цена — более сложный контроль совместимости. Поле нельзя бездумно удалить только потому, что один клиент его больше не использует: сначала нужно проверить, кто ещё отправляет такой запрос.

Команда готова владеть схемой как продуктом

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

Сравнение цены решения

Два подхода, которые часто выбирают неправильно

«GraphQL уберёт все лишние запросы»

Один запрос от клиента не гарантирует один запрос к базе. Неудачные резолверы могут создать N+1: сначала сервер получает список сущностей, а затем отдельно обращается за связанными данными для каждой строки. На небольшом тестовом наборе это незаметно, а в проде задержка растёт вместе с размером списка.

Для GraphQL нужны пакетная загрузка, лимиты на размер выборки и наблюдаемость по полям. Конкретный механизм зависит от языка и библиотеки, поэтому не стоит переносить в статью название инструмента как универсальный рецепт.

«REST нельзя использовать для сложного интерфейса»

REST можно адаптировать под сложные экраны: добавить агрегирующий endpoint, параметры выборки или отдельные представления. Это увеличивает дизайн-код и требования к контракту, но иногда дешевле, чем внедрять GraphQL во все сервисы.

Агрегирующий endpoint не должен становиться скрытым GraphQL без схемы: если его ответ меняется под десятки сценариев, документация, права и совместимость быстро становятся отдельной проблемой.

Что ломается в проде

• GraphQL без лимитов. Вложенный запрос может заставить сервер пройти слишком глубокое дерево или вернуть тысячи объектов. Ограничивайте глубину, сложность, размер списков, таймаут и общий бюджет работы запроса.
• REST с бесконечными параметрами. Endpoint с десятками фильтров и форматов перестаёт быть предсказуемым. Зафиксируйте поддерживаемые параметры и отдельно измеряйте самые дорогие комбинации.
• Нечёткие права в GraphQL. Скрытие поля в интерфейсе не защищает данные. Проверка доступа должна выполняться на сервере и учитывать пользователя, объект и конкретное поле, если это требуется моделью доступа.
• Версия только на бумаге. REST-URL с номером версии не спасает от несовместимых изменений, а GraphQL-схема не делает удаление поля безопасным. В обоих случаях нужны журнал изменений, метрики использования и период вывода старых контрактов.
• Нет трассировки. В REST ищут медленный URL, в GraphQL — конкретный запрос и поле, которое породило задержку. Без корреляционного идентификатора и распределённой трассировки расследование будет строиться на догадках.

Как выбрать без религиозной войны

1. Опишите клиентов. Если это один веб-клиент и несколько стандартных интеграций, начните с REST. Если клиентов много и им нужны сильно разные представления одних данных, рассмотрите GraphQL.
2. Посчитайте форму чтения. Выпишите пять самых тяжёлых экранов и укажите, сколько источников они объединяют. Если почти каждый экран требует цепочки запросов, GraphQL или отдельный BFF¹ могут снизить связность клиента.
3. Проверьте инфраструктуру. Если CDN, прокси и кеши — важная часть архитектуры, REST обычно требует меньше специальных решений. Для GraphQL заранее опишите кеширование, авторизацию и правила повторного использования результатов.
4. Оцените команду. GraphQL стоит выбирать только вместе с владельцем схемы, правилами эволюции и мониторингом стоимости запросов. Если этих ресурсов нет, гибкость окажется долгом.
5. Сделайте нагрузочный сценарий. Сравните не среднее время ответа, а p95 и p99, количество обращений к базе, объём ответа, долю ошибок и поведение при пустых или больших выборках. Сценарии и железо зафиксируйте, иначе сравнение будет необъективным.

¹ BFF, Backend for Frontend, — отдельный серверный слой под конкретный клиент. Он может собрать данные из нескольких сервисов и не обязан быть GraphQL.

Когда допустим гибрид

Не обязательно выбирать один стиль для всей компании. REST может обслуживать платежи, загрузку файлов и публичные интеграции, где важны стабильные ресурсы и понятные HTTP-операции. GraphQL может стать фасадом для веб-приложения, если ему нужно объединять данные нескольких доменов.

Граница должна быть явной. Определите, какой слой отвечает за авторизацию, кеширование, лимиты и преобразование ошибок. Иначе один и тот же запрос начнёт проходить через несколько независимых политик.

Что делать дальше

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

После запуска смотрите на p95 и p99 задержки, ошибки по операциям, количество обращений к базе и самые часто используемые поля или endpoints. Если GraphQL внедряется впервые, сначала ограничьте его одним доменом. Если REST уже перегружен специализированными endpoints, начните с узкого BFF и сравните его цену с полноценной схемой.