REST vs GraphQL: какое API выбрать для проекта в 2026 году

Спор «REST vs GraphQL» часто ведут как спор вкусов, хотя на деле это решение о деньгах и сроках. От стиля API зависит, сколько запросов сделает каждый экран приложения, как быстро фронтенд-команда сможет менять интерфейс без помощи бэкенда, во что обойдётся защита от тяжёлых запросов и сколько будет стоить поддержка через три года. Поэтому, когда мы берёмся за задачи по разработке сайтов и веб-сервисов, стиль API обсуждаем на этапе архитектуры: позже менять его дорого.

Статья написана для CTO, техлидов и владельцев продукта, которые выбирают подход перед стартом разработки или рефакторингом. Ниже — как устроены оба подхода, сравнительная таблица, разбор кэширования, безопасности и лимитов, сценарии выбора, стоимость по статьям затрат, пошаговая миграция и чек-лист. Учебных примеров «для первого API» здесь минимум: только то, что влияет на решение.

Что такое REST API и как он работает

REST (Representational State Transfer) — архитектурный стиль, который Рой Филдинг описал в своей диссертации в 2000 году. Это не протокол и не стандарт, а набор ограничений: разделение клиента и сервера, отсутствие состояния между запросами, кэшируемость ответов, единообразный интерфейс и многоуровневая система. Почти все современные REST API работают поверх HTTP и обмениваются JSON.

Центральное понятие REST — ресурс. Пользователь, заказ, товар — у каждого свой адрес (URL), а действия над ним выражаются HTTP-методами:

• GET — получить ресурс или список;
• POST — создать ресурс;
• PUT / PATCH — заменить или частично изменить;
• DELETE — удалить.

Результат сообщает код состояния HTTP: 200 — успех, 201 — создано, 404 — не найдено, 409 — конфликт, 500 — ошибка сервера. Форму ответа определяет сервер: эндпоинт всегда возвращает одну и ту же структуру. Чтобы показать профиль пользователя и его заказы, клиент обычно делает два запроса:

GET /api/v1/users/42
GET /api/v1/users/42/orders

Сильная сторона REST — опора на сам HTTP. GET-запросы кэшируются браузером, прокси и CDN по заголовкам Cache-Control и ETag, поведение предсказуемо для любого инструмента: от curl до API-шлюза и WAF. По формулировке AWS в сравнении GraphQL и REST, REST подходит для простых источников данных с чётко определёнными ресурсами. Слабая сторона — схема необязательна: контракт описывают отдельно (обычно в OpenAPI), а проверку корректности данных во многом берёт на себя клиент. Как вписать REST API в общую архитектуру клиента и сервера, мы разбирали в статье «Клиент-серверная архитектура: как разрабатывать web API».

Что такое GraphQL и как он работает

GraphQL — язык запросов к API и среда выполнения этих запросов на сервере. Его создали в Facebook (по данным AWS, в 2012 году), затем опубликовали спецификацию. Сегодня, по данным официального FAQ GraphQL, проектом управляет нейтральный GraphQL Foundation под эгидой Linux Foundation, и Facebook им не владеет. Это важно для бизнеса: стандарт открытый, и риск зависимости от одной компании минимален.

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

• query — чтение данных;
• mutation — изменение данных;
• subscription — подписка на события в реальном времени.

Тот же экран «профиль и заказы» описывается одним запросом:

query {
  user(id: 42) {
    name
    orders(first: 5) {
      id
      total
      status
    }
  }
}

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

В чём разница между REST и GraphQL — сравнительная таблица

Таблица REST vs GraphQL собирает различия, которые влияют на архитектуру, сроки и эксплуатацию. Это не оценка «лучше — хуже»: у каждой строки есть сценарии, где выигрывает любая из сторон.

Критерий	REST	GraphQL
Эндпоинты	Много URL, по одному на ресурс или коллекцию	Как правило, один URL для всех операций
Форма ответа	Задаёт сервер, структура фиксирована	Задаёт клиент, получает только запрошенные поля
Схема и типизация	Опциональна (OpenAPI описывают отдельно)	Обязательна, строгая типизация
Over-/under-fetching	Типичны: лишние поля или нехватка данных	Решаются запросом нужных полей
Запросов на экран	Часто несколько	Обычно один
Кэширование	Стандартный HTTP-кэш, CDN, ETag	Нужна отдельная стратегия: клиентский кэш, persisted queries
Версионирование	/v1, /v2, заголовки	Эволюция схемы без версий, пометка устаревших полей
Ошибки	HTTP-коды 4xx/5xx	Чаще всего HTTP 200, ошибки в поле errors
Реальное время	Отдельно: вебхуки, SSE, WebSocket	Встроенный тип операции subscription
Документация	OpenAPI/Swagger, нужно поддерживать	Интроспекция схемы, генерируется автоматически
Порог входа для команды	Низкий, знаком почти всем	Выше: схема, резолверы, N+1, лимиты
Зрелость инструментов	Максимальная: шлюзы, WAF, мониторинг	Зрелая экосистема, но часть инструментов специфична
Защита от тяжёлых запросов	Rate limit по числу вызовов эндпоинтов	Нужен учёт глубины и стоимости запроса

Если свести таблицу к одной мысли: REST перекладывает сложность на клиента (собрать данные из нескольких ответов), GraphQL — на сервер (быстро и безопасно выполнить произвольный запрос). Разница между REST и GraphQL — вопрос того, где вам дешевле держать эту сложность.

Получение данных: over-fetching, under-fetching и число запросов

Возьмём экран заказа в мобильном приложении магазина. На нём имя покупателя, статус доставки, три товара с картинками и бонусный баланс. В REST-подходе клиент, скорее всего, вызовет /orders/{id}, /users/{id}, /products/{id} по каждому товару и /loyalty/{id}. Это under-fetching (недостаточная выборка): одного ответа не хватает, нужно несколько последовательных запросов. Одновременно возникает over-fetching (избыточная выборка): эндпоинт товара отдаёт полное описание, характеристики и отзывы, хотя экрану нужны только название, цена и картинка.

На быстром Wi-Fi это почти незаметно. В мобильной сети каждый дополнительный круг запроса добавляет задержку, а лишние килобайты — расход трафика и батареи. AWS отдельно отмечает, что GraphQL особенно хорош, когда канал ограничен: клиент получает за один запрос ровно те поля, которые нужны экрану.

У REST есть свои способы бороться с этой проблемой, и их стоит знать, прежде чем менять архитектуру:

• Параметры выборки полей — например, ?fields=name,price,image;
• Встраивание связанных ресурсов — ?include=items,customer;
• Агрегирующие эндпоинты под экран — специальный /screens/order/{id}, который собирает всё нужное на сервере;
• BFF (Backend for Frontend) — отдельный тонкий бэкенд под конкретного клиента.

Все эти приёмы работают, но каждый новый экран требует доработки на бэкенде. Если экранов много, а клиентов несколько, команда бэкенда становится узким местом. GraphQL снимает эту зависимость: фронтенд меняет запрос, а бэкенд трогать не нужно, пока нужные поля уже есть в схеме. Подробнее о том, как спроектировать бэкенд под мобильного клиента, — в статье «API для мобильного приложения».

Кэширование и производительность: что быстрее на практике?

Универсального ответа нет: скорость определяется реализацией, а не стилем API. Быстрый REST и медленный GraphQL встречаются так же часто, как наоборот. Важнее понимать, где у каждого подхода «бесплатная» производительность и за что придётся платить отдельно.

REST и кэш. GET-запрос на уникальный URL — идеальный кандидат для HTTP-кэша. Браузер, промежуточный прокси и CDN кэшируют ответ по стандартным заголовкам, а ETag позволяет отдавать «ничего не изменилось» без тела ответа. Для каталога товаров, публичного контента или справочников это даёт огромный выигрыш без строчки дополнительного кода.

GraphQL и кэш. Классический GraphQL отправляет POST-запросы на один URL, и HTTP-кэш с CDN такие запросы по умолчанию не кэшируют: для них все запросы одинаковые. Поэтому кэширование в GraphQL строят иначе:

• Нормализованный клиентский кэш — клиентские библиотеки (Apollo Client, urql) хранят объекты по идентификаторам и переиспользуют их между экранами;
• Persisted queries — запрос заранее регистрируется на сервере и вызывается по хешу; такие запросы можно отправлять через GET и кэшировать на CDN;
• Кэш на уровне резолверов и источников данных — на сервере, как в любом бэкенде.

Итог по кэшированию: если основная нагрузка — массовое чтение одинаковых публичных данных, REST с CDN проще и дешевле. Если данные персональные (личный кабинет, лента, CRM), CDN всё равно мало помогает, и преимущество REST сокращается.

Проблема N+1 и как её решают

Главный риск производительности GraphQL на сервере — проблема N+1. Запрос «10 заказов и покупатель каждого заказа» наивная реализация выполнит как 1 запрос к базе за заказами и ещё 10 запросов за покупателями: резолвер поля customer вызывается для каждого заказа отдельно. На вложенных запросах число обращений к базе растёт лавинообразно.

Стандартное решение, которое упоминает и FAQ GraphQL, — пакетная загрузка (batching) через DataLoader или аналоги: резолверы не идут в базу сразу, а складывают идентификаторы в очередь, и в конце такта выполняется один запрос WHERE id IN (...). Дополнительно помогают кэш на время запроса и мониторинг самых дорогих операций. Важно другое: в REST эту оптимизацию за разработчика делает фиксированная форма эндпоинта, в GraphQL её нужно закладывать в архитектуру с первого дня.

Версионирование, ошибки и документация

Эти три темы определяют, насколько дорого будет жить с API годами. Здесь различия между REST и GraphQL особенно заметны.

Версионирование: /v1, /v2 или эволюция схемы

В REST изменения, ломающие контракт, обычно выпускают новой версией: /api/v2/orders рядом со старой /api/v1/orders. Это понятно и надёжно, но каждая живая версия — код, тесты и документация, которые нужно поддерживать, пока последний клиент не обновится. С мобильными приложениями это годы: пользователи не обновляются по команде.

GraphQL, по формулировке его FAQ, избегает версионирования by design: новые поля и типы добавляются в схему без поломки существующих клиентов, потому что старые клиенты их просто не запрашивают. Устаревшее поле помечают директивой @deprecated, отслеживают, кто им ещё пользуется, и удаляют, когда запросов не осталось. Это не отменяет дисциплины: переименовать поле или поменять его тип «тихо» нельзя и в GraphQL.

Ошибки: HTTP-коды против поля errors

REST использует коды состояния HTTP, и это сильная сторона: мониторинг, балансировщики и API-шлюзы сразу видят долю ответов 4xx и 5xx. В GraphQL сервер обычно отвечает HTTP 200, а ошибки кладёт в массив errors рядом с частично успешными данными в поле data. Такой ответ честнее для сложных запросов (часть полей получена, часть — нет), но требует настроить мониторинг и алертинг по содержимому ответа, а не по коду. Хорошая практика — договориться о кодах ошибок в поле extensions и описать их в документации.

Документация: OpenAPI/Swagger и интроспекция

Для REST стандарт де-факто — спецификация OpenAPI (бывший Swagger). По ней генерируют интерактивную документацию, клиентские SDK и тесты контракта. Но спецификацию нужно поддерживать в актуальном состоянии: если её пишут отдельно от кода, она быстро отстаёт. В GraphQL схема и есть контракт: интроспекция отдаёт её в машиночитаемом виде, а инструменты разработчика строят документацию и автодополнение сами. Описания полей всё равно пишут люди, но рассинхрона «код говорит одно, документация другое» здесь меньше.

Безопасность и лимиты: чем рискует GraphQL-эндпоинт?

Гибкость GraphQL — это и его главная поверхность атаки. Клиент может составить запрос любой глубины и ширины: «пользователи → их друзья → их заказы → товары в заказах → отзывы к товарам». Один такой запрос способен нагрузить базу сильнее, чем тысяча обычных. Поэтому защищать GraphQL-эндпоинт простым ограничением «N запросов в минуту» недостаточно.

Хороший публичный ориентир — документация GitHub по лимитам GraphQL API. GitHub считает лимит не в запросах, а в «очках» стоимости:

• 5 000 очков в час на пользователя (для GitHub Enterprise Cloud — до 10 000);
• не больше 500 000 узлов в одном вызове;
• аргументы пагинации first и last — от 1 до 100;
• запрос, который выполняется дольше 10 секунд, обрывается с ошибкой.

Вывод для проектирования: в GraphQL нужно считать стоимость запроса (query cost) ещё до выполнения, а в REST достаточно считать вызовы. Минимальный набор защиты GraphQL-API:

• Ограничение глубины и сложности запроса — запросы сверх лимита отклоняются до выполнения;
• Обязательная пагинация с верхней границей размера страницы;
• Тайм-ауты на выполнение запроса и обращения к источникам данных;
• Интроспекция выключена в проде для публичных API или доступна только авторизованным разработчикам;
• Persisted queries / allowlist — для собственных клиентов разрешены только заранее зарегистрированные запросы;
• Авторизация на уровне полей и объектов, а не только «на входе»: один эндпоинт отдаёт данные разной чувствительности.

REST тоже нужно защищать, но инструменты стандартные: rate limit по эндпоинтам и ключам, WAF, проверка прав на уровне ресурса, всё это обычно живёт в API-шлюзе. Если у вас несколько сервисов, полезно вынести эти задачи в единую точку входа — подробнее в статье «Что такое API Gateway и зачем он нужен». Современные шлюзы умеют работать и с GraphQL-трафиком, но правила для него настраивают отдельно.

Когда выбрать REST?

REST — разумный выбор по умолчанию, если в продукте нет явных причин для GraphQL. Типичные сценарии:

1. Публичное или партнёрское API. Внешние разработчики ждут привычных эндпоинтов, HTTP-кодов и OpenAPI-документации. Порог входа ниже, а лимиты проще объяснить и посчитать.
2. Простая CRUD-модель. Если сущностей немного и связи между ними неглубокие (заявки, справочники, админка), GraphQL добавит инфраструктуры больше, чем пользы.
3. Важны CDN и HTTP-кэш. Каталоги, контентные сайты, публичные справочники с массовым чтением одинаковых данных выигрывают от стандартного кэширования.
4. Интеграции и вебхуки. Платёжные системы, учётные системы, CRM почти всегда общаются через REST и вебхуки — проще говорить с ними на одном языке.
5. Небольшая команда или MVP. REST знают все, его быстрее запустить и проще поддерживать, когда в команде один-два бэкенд-разработчика.
6. Файлы и большие бинарные данные. Загрузка и отдача файлов, стриминг медиа естественно ложатся на HTTP-эндпоинты; в GraphQL для этого всё равно делают отдельные REST-маршруты или подписанные ссылки.

Когда выбрать GraphQL?

GraphQL окупается, когда сложность данных и число клиентов растут быстрее, чем команда бэкенда. Типичные сценарии:

1. Несколько клиентов с разными экранами. Веб, iOS и Android показывают одни и те же данные по-разному. Каждый клиент запрашивает свои поля из общей схемы, и бэкенду не нужно делать эндпоинт под каждый экран. Это частый случай, когда параллельно идёт разработка мобильных приложений и веб-версии.
2. Сложный граф связанных сущностей. Маркетплейс, соцсеть, CRM, LMS — там, где «пользователь → заказы → товары → продавцы → отзывы» и экраны собирают данные из разных веток графа.
3. Дашборды и аналитические интерфейсы. Виджеты с разными наборами метрик удобно описывать отдельными запросами к одной схеме. Если это сложное SPA, учитывайте и выбор подхода к рендерингу — см. «SPA, MPA или SSR: как выбрать».
4. Частые изменения интерфейса. Продуктовая команда регулярно экспериментирует с экранами, и ждать релиза бэкенда под каждое изменение дорого.
5. Агрегация нескольких сервисов. Данные живут в разных микросервисах и внешних системах, а клиенту нужна одна точка доступа. По оценке AWS, GraphQL хорошо подходит, чтобы свести несколько источников в один эндпоинт: так строят BFF-слой и федерацию схем.

REST и GraphQL вместе: гибрид и пошаговая миграция

Выбор «REST или GraphQL» не обязан быть взаимоисключающим. FAQ GraphQL прямо говорит, что GraphQL часто рассматривают как альтернативу REST, но не как его окончательную замену, и что оба подхода могут сосуществовать в одном стеке. Живой пример — GitHub: у него параллельно работают REST API и GraphQL API, и лимиты у каждого свои.

На практике встречаются три устойчивые схемы:

• REST наружу, GraphQL для своих клиентов. Партнёры и интеграции работают с документированным REST API, а собственные веб- и мобильные приложения — с GraphQL-слоем.
• GraphQL как фасад над REST. Существующие REST-сервисы остаются как есть, а сверху появляется GraphQL-слой (BFF), который собирает данные для клиентов. Резолверы при этом вызывают уже готовые REST-эндпоинты.
• REST для файлов и вебхуков, GraphQL для данных. Загрузка медиа, отдача документов и приём событий от внешних систем остаются на HTTP-маршрутах.

Как перейти с REST на GraphQL без остановки продукта

Переписывать API целиком почти никогда не нужно. Рабочая стратегия — постепенный переход, при котором продукт продолжает работать:

1. Аудит экранов и запросов. Найдите экраны, которые делают больше всего запросов или тянут больше всего лишних данных. Это кандидаты на перевод в первую очередь.
2. Схема под одного клиента. Начните с одного приложения, например мобильного, и спроектируйте схему вокруг его реальных экранов, а не вокруг таблиц базы данных.
3. GraphQL-слой поверх существующих сервисов. Резолверы на первом этапе вызывают текущие REST-эндпоинты. Бэкенд не трогаем, сразу закладываем DataLoader и лимиты сложности.
4. Перевод экранов по одному. Каждый экран переключается на GraphQL отдельно, со сравнением поведения и метрик. Старые эндпоинты продолжают работать.
5. Мониторинг стоимости запросов. Отслеживайте самые тяжёлые операции, время резолверов и ошибки в поле errors, а не только HTTP-коды.
6. Отказ от неиспользуемых эндпоинтов. Когда по логам видно, что REST-маршрут больше никто не вызывает (с учётом старых версий мобильных приложений), его можно выводить из эксплуатации.

Такой переход можно остановить на любом шаге: если гибрид устраивает, дальше идти не обязательно.

А как же gRPC?

gRPC решает другую задачу: это RPC-фреймворк поверх HTTP/2 с бинарной сериализацией в Protocol Buffers, и его сильная сторона — быстрый обмен между внутренними сервисами и стриминг. Для браузерного клиента он неудобен без прокси, поэтому в сравнении «какое API выбрать для фронтенда и мобайла» обычно спорят REST и GraphQL, а gRPC живёт внутри. Подробный разбор — в статье «gRPC vs REST: в чём разница и что выбрать для API».

Стоимость и сроки разработки API: REST или GraphQL

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

Статья затрат	REST	GraphQL
Старт и первая версия API	Ниже: знакомые инструменты, быстрый запуск	Выше: схема, резолверы, серверная инфраструктура
Защита от тяжёлых запросов	Ниже: стандартный rate limit и шлюз	Выше: глубина, стоимость запроса, allowlist
Кэширование	Ниже: HTTP-кэш и CDN из коробки	Выше: клиентский кэш, persisted queries
Оптимизация производительности сервера	Сопоставимо	Выше на старте: DataLoader, профилирование резолверов
Обучение команды	Ниже: стиль знаком почти всем	Выше, если опыта GraphQL нет
Доработки бэкенда под новые экраны	Выше: новые эндпоинты и параметры	Ниже: клиенты сами выбирают поля из схемы
Поддержка версий через 2–3 года	Выше: несколько живых версий API	Ниже: эволюция схемы без версий
Работа фронтенда и мобайла	Выше: сборка данных из нескольких ответов	Ниже: один запрос на экран, типы из схемы
Документация	Сопоставимо при генерации OpenAPI из кода	Ниже: схема и интроспекция

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

Чек-лист: как выбрать API для своего проекта

Ответьте на вопросы ниже. Если большинство ответов указывает в одну сторону — выбор очевиден; если ответы разделились, присмотритесь к гибриду.

• Сколько клиентов будет у API? Один веб-интерфейс — REST. Веб плюс iOS и Android с разными экранами — GraphQL или гибрид.
• Публичное ли это API? Да, для внешних разработчиков и партнёров — REST. Только для своих приложений — подойдут оба.
• Нужен ли CDN-кэш для массового чтения одинаковых данных? Да — REST. Данные в основном персональные — разница невелика.
• Насколько связаны данные? Плоские сущности и CRUD — REST. Глубокий граф связей — GraphQL.
• Как часто меняется интерфейс? Редко — REST. Постоянные эксперименты с экранами — GraphQL.
• Есть ли в команде опыт GraphQL? Нет и сроки жёсткие — REST. Есть или время на обучение заложено — GraphQL.
• Сколько источников данных за API? Один бэкенд и одна база — REST. Несколько микросервисов и внешних систем — GraphQL как слой агрегации.
• Много ли файлов и медиа? Да — REST-эндпоинты для файлов в любом случае.
• Нужны ли события в реальном времени? Подписки в GraphQL удобны, но для простых случаев хватает вебхуков или SSE рядом с REST.
• Есть ли ресурс на защиту и мониторинг сервера? Нет — REST безопаснее по умолчанию. Да — GraphQL можно запускать и на публичную аудиторию.

Как YuSMP Group проектирует API

Мы не выбираем стиль API заранее. Сначала разбираем, какие клиенты будут у продукта сейчас и через год, какие экраны и сценарии данных за ними стоят, какие интеграции и требования к нагрузке есть. По итогам предлагаем REST, GraphQL или гибрид с обоснованием, документируем контракт (OpenAPI или схему GraphQL) до начала разработки и закладываем лимиты, мониторинг и план развития версий. Если вам нужна разработка API под ключ или аудит существующего, начнём с такого разбора.

Часто задаваемые вопросы

GraphQL заменит REST?

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

Что быстрее — REST или GraphQL?

Универсального ответа нет: скорость определяет реализация. GraphQL сокращает число запросов и объём лишних данных, что особенно заметно в мобильных сетях. REST выигрывает там, где работают HTTP-кэш и CDN. Плохо реализованный GraphQL с проблемой N+1 будет медленнее аккуратного REST, поэтому решение стоит проверять на прототипе ключевого сценария.

Можно ли кэшировать GraphQL-запросы?

Да, но иначе, чем REST. Обычные POST-запросы на один URL CDN не кэширует, поэтому используют нормализованный кэш на клиенте (Apollo Client, urql), persisted queries, которые можно отправлять через GET и кэшировать на CDN, а также кэш на уровне резолверов и источников данных на сервере.

Что выбрать для мобильного приложения?

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

Подходит ли GraphQL для MVP?

Чаще нет, если в команде нет опыта GraphQL. MVP важно запустить быстро, а GraphQL требует времени на схему, резолверы, защиту от тяжёлых запросов и кэширование. Исключение — команда, которая уже работает с GraphQL, и продукт, где с первого дня несколько клиентов и сложный граф данных.

Безопасен ли GraphQL для публичного API?

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

Можно ли использовать REST и GraphQL в одном проекте?

Да, и это частый вариант. Например, REST API для партнёров, файлов и вебхуков, а GraphQL — для собственных веб- и мобильных клиентов. Другой вариант — GraphQL-слой поверх существующих REST-сервисов. Так работает, например, GitHub, у которого параллельно живут REST API и GraphQL API.

Чем GraphQL отличается от gRPC?

GraphQL — язык запросов, где клиент выбирает нужные поля, и он ориентирован на фронтенд и мобильные приложения. gRPC — RPC-фреймворк с бинарным форматом Protocol Buffers и HTTP/2, который чаще используют для быстрого обмена между внутренними сервисами. Их нередко сочетают: gRPC внутри системы, GraphQL или REST снаружи.

Сложно ли перейти с REST на GraphQL?

Не обязательно, если идти постепенно. Поверх существующих REST-сервисов ставят GraphQL-слой, переводят на него экраны по одному и отключают старые эндпоинты, когда их перестают вызывать. Основные трудности — проектирование схемы под реальные экраны, решение проблемы N+1 и настройка лимитов и мониторинга.

Вывод: REST или GraphQL — как принять решение

REST vs GraphQL — не спор старого и нового, а выбор места, где вы держите сложность: на клиентах или на сервере. Оба подхода зрелые, и правильный ответ зависит от продукта и команды.

Выбирайте REST, если:

• API публичное или партнёрское;
• модель данных простая, а клиент один;
• важны CDN и HTTP-кэш для массового чтения;
• команда небольшая, а сроки MVP жёсткие.

Выбирайте GraphQL, если:

• у продукта несколько клиентов с разными экранами;
• данные образуют сложный граф связей;
• интерфейс часто меняется;
• нужно свести несколько сервисов в одну точку доступа, а в команде есть ресурс на защиту и мониторинг сервера.

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