REST против GraphQL против gRPC: структура принятия решений на 2026 год

Ваша команда запускает новый сервис. Кто-то открывает тему в Slack: «Должны ли мы использовать GraphQL?» Кто-то другой отвечает со ссылкой на тест gRPC. Нить разделилась на три лагеря. Два часа спустя никакого решения.

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

Это руководство дает вам конкретную основу для принятия решений, а не «это зависит». Каждый протокол получает определенное вариант использования, в котором он выигрывает, пример кода, который вы можете запустить, и сравнительную таблицу, в которую вы можете вставить проектный документ.

30-секундный фреймворк

Начните с трех вопросов:

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

Ответы отображаются непосредственно в протоколе:

• ОТДЫХ выигрывает, когда аудитория внешняя, форма данных фиксирована и кэширование имеет значение.
• ГрафQL выигрывает, когда нескольким клиентам нужны разные фрагменты одного и того же графа данных.
• gRPC выигрывает, когда внутренние службы общаются друг с другом, а пропускная способность важнее, чем читабельность для человека.

Вот та же логика, что и в коде:

ОТДЫХ: универсальное значение по умолчанию.

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

REST — правильный выбор для общедоступных API, где вы контролируете форму данных, а клиенты ожидают стабильной и стабильной работы. документированные конечные точки. Все более 150 конечных точек API botoi используют REST. Вот поиск DNS:

Ответ:

Запрос представляет собой один POST. Ответ представляет собой плоский объект JSON. Вы можете проверить это с помощью завитка, конвейера через jqили вызовите его на любом языке с помощью fetch. Нет файла схемы для компиляции, нет языка запросов для изучения, нет этапа генерации кода.

Где сияет REST

• Публичные API-интерфейсы для разработчиков. Сторонние разработчики ожидают REST. Стоимость подключения равна нулю.
• Кэшируемые ресурсы. HTTP-кэширование работает на всех уровнях: браузер, CDN, обратный прокси. А GET /users/123 ответ с правильными заголовками кэша ничего не стоит при повторных запросах.
• Интеграция вебхуков. Вебхуки — это запросы HTTP POST. REST соответствует ментальной модели.
• Простые операции CRUD. Когда каждая конечная точка выполняет одно действие с одной входной формой и одной выходной формой, REST не добавляет накладных расходов.

Где REST терпит неудачу

• Чрезмерная выборка. Мобильное приложение, которому требуется 3 поля из профиля пользователя, все равно загружает полный объект из 40 полей.
• Неполная выборка. Панель мониторинга, показывающая пользователя, его команду и его недавнюю активность, выполняет 3 последовательных HTTP-вызова. Задержка складывается.
• Нет встроенной эволюции схемы. Вы создаете URL-адреса (/v1/, /v2/) или добавлять поля и надеяться, что клиенты игнорируют неизвестные ключи.

GraphQL: запросы, управляемые клиентом

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

Публичный API GitHub хорошо это демонстрирует. Один запрос извлекает ваше имя пользователя и три лучших репозитория. со количеством звезд и основным языком. В REST для этого потребуется как минимум 2 вызова.

Ответ:

Клиент попросил name, stargazerCount, и primaryLanguage. Сервер вернул именно эти поля. Никакие дополнительные данные не передаются. Никакого второго запроса.

Где сияет GraphQL

• Мобильные приложения. Пропускная способность ограничена. Размер полезной нагрузки имеет значение. GraphQL устраняет чрезмерную выборку на каждом экране.
• Панели мониторинга и представления агрегирования. Один запрос может получить данные от пользователей, заказов и запасов за один проход.
• Быстрая итерация интерфейса. Фронтенд-команды меняют свои запросы, не дожидаясь, пока бэкэнд-команды создадут новые конечные точки.
• Сильная типизация. Схема — это контракт. Инструменты генерации кода, такие как GraphQL Code Generator, создают на его основе типы TypeScript.

Где GraphQL терпит неудачу

• Кэширование. Каждый запрос представляет собой POST для /graphql. HTTP-кэширование на уровне CDN или браузера не работает без уровня постоянных запросов или запросов на основе GET.
• Поверхность безопасности. Клиенты могут писать дорогостоящие запросы, которые объединяют глубоко вложенные данные. Вам необходим анализ стоимости запросов и ограничение глубины, чтобы предотвратить злоупотребления.
• Кривая обучения. Разработчикам необходимо изучить язык запросов, структуру схемы, преобразователи и шаблоны DataLoader. Время разгона больше, чем REST.
• N+1 запросов. Шаблоны наивных преобразователей запускают один запрос к базе данных для каждого элемента списка. Пакетная обработка DataLoader исправляет эту проблему, но вам придется создавать ее самостоятельно.

gRPC: внутренняя скорость

gRPC использует буферы протокола для сериализации и HTTP/2 для транспорта. Вы определяете свой сервис контракт в .proto файл, генерировать клиентский и серверный код и получать типобезопасные вызовы RPC. с двоичными полезными нагрузками.

Из этого определения protoc генерирует клиентские заглушки и серверные интерфейсы на Go, Java, Python, Rust, C++ и дюжина других языков. Сгенерированный код обрабатывает сериализацию, десериализацию, и кадрирование HTTP/2.

Где сияет gRPC

• Межсервисная связь. Внутренние микросервисы, которые обмениваются высокочастотными сообщениями, выигрывают от двоичной сериализации и мультиплексирования потоков.
• Строгие контракты. The .proto файл является единственным источником истины. Критические изменения фиксируются во время компиляции, а не во время выполнения.
• Двунаправленная потоковая передача. gRPC поддерживает потоковую передачу с сервера, потоковую передачу с клиента и двунаправленную потоковую передачу. Функции реального времени, такие как потоки транзакций в реальном времени, подходят естественно.
• Полиглотская среда. Служба Go может вызывать службу Python через сгенерированные заглушки без кода сериализации вручную.

Где gRPC терпит неудачу

• Поддержка браузера. Браузеры не могут выполнять собственные вызовы gRPC. Прокси-сервер grpc-web добавляет уровень сложности и задержки.
• Читабельность для человека. Двоичные полезные нагрузки не подлежат проверке с помощью curl или инструменты разработки браузера. Для отладки требуются специальные инструменты, такие как grpcurl или Блум РПК.
• Зрелость экосистемы. REST имеет десятилетия инструментов: Postman, Swagger, шлюзы API, ограничители скорости. Инструментарий gRPC растет, но не на том же уровне.
• Кривая обучения. Команды должны изучить буферы протоколов, синтаксис proto3, конвейеры генерации кода и шаблоны обработки ошибок, специфичные для gRPC.

Сравнительная таблица

Примеры решений из реальной жизни

Stripe: REST для платежей

Stripe обрабатывает платежи на миллиарды долларов через REST API. Их конечные точки следуют предсказуемому узоры: POST /v1/payment_intents, GET /v1/charges/:id. Каждый разработчик кто интегрирует Stripe, знает HTTP. Трудности при приеме на работу близки к нулю. Stripe выбрал REST, потому что их аудитория — внешние разработчики, которым нужны стабильные, документированные и кэшируемые конечные точки.

GitHub: GraphQL для инструментов разработчика

GitHub перешёл с REST (v3) на GraphQL (v4), поскольку их клиенты (приложения для ПК, мобильные приложения, сторонние интеграции) всем нужны были разные данные из одних и тех же объектов. Инструмент CI требует фиксации статус и проверочные прогоны. Приложению для управления проектами нужны задачи, метки и исполнители. Мобильное приложение требуется минимальный вид профиля. Одна конечная точка REST не могла бы обслуживать все три без массовой избыточной выборки.

Google: gRPC для внутренних сервисов

Google создал gRPC («g» означает новое слово в каждом выпуске) для управления внутренним межсервисным взаимодействием. общение в масштабе. Когда ваша сервисная сетка обрабатывает миллионы RPC в секунду, разница между синтаксическим анализом текста JSON и двоичной десериализацией протокольного буфера. Google выбрал gRPC, потому что аудитория внутренняя, контракты строгие, а пропускная способность является основным ограничением.

Почему botoi выбрал REST для более чем 150 конечных точек

API botoi обслуживает независимые конечные точки утилит: поиск DNS, проверка электронной почты, форматирование JSON, QR-код. генерация, вычисление хеша. Каждая конечная точка принимает определенные входные данные и возвращает определенный выходной сигнал. Не существует графа реляционных данных, связывающего запись DNS с QR-кодом.

Три фактора сделали выбор REST очевидным:

• Универсальная поддержка клиентов. Разработчики вызывают ботои из Node.js, Python, Go, Ruby, PHP, сценарии оболочки и агенты ИИ. REST работает во всех из них без каких-либо настроек.
• Кэшируемость. GET конечные точки для статических ресурсов (например, поиск по странам или списки валют). извлечь выгоду из HTTP-кэширования на уровне CDN. Это позволяет сократить время ответа до 20 мс для повторных запросов.
• Обнаруживаемость. Каждая конечная точка имеет стабильный URL-адрес, запись спецификации OpenAPI и интерактивный интерфейс. документы через скаляр. Новые разработчики находят и тестируют конечные точки менее чем за минуту.

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

Смешение протоколов в одной системе

Структура применяется к границам, а не к организации. Многие производственные системы объединяют протоколы:

• Внешний уровень API: ОТДЫХ. Сторонние разработчики и веб-перехватчики ожидают HTTP + JSON.
• Клиентский шлюз: ГрафQL. Мобильные и веб-клиенты запрашивают шлюз, который объединяет данные из нескольких служб.
• Внутренняя сервисная сетка: гРПК. Серверные службы взаимодействуют с двоичными полезными данными и строгими контрактами.

Это не сложность ради сложности. Каждая граница имеет разную аудиторию с разными ограничения. Протокол должен соответствовать ограничению, а не наоборот.

Контрольный список решений

Скопируйте это в свой дизайнерский документ. Ответьте на каждый вопрос, и выбор протокола станет очевидным.

1. Кто является потребителями API? Внешние разработчики (REST), собственная фронтенд-команда (GraphQL), внутренние сервисы (gRPC).
2. Сколько форм данных запрашивают клиенты? Одна фигура (REST), множество фигур (GraphQL), фиксированные контракты (gRPC).
3. Имеет ли значение HTTP-кэширование? Да (REST), иногда (GraphQL с усилием), нет (gRPC).
4. Вам нужна потоковая передача? Нет (REST в порядке), подписки (GraphQL), двунаправленная передача (gRPC).
5. Какие языки используют клиенты? Все (REST), тяжелый JS/TS (инструменты GraphQL здесь самые сильные), полиглот с генерацией кода (gRPC).
6. Каков текущий опыт команды? Если никто не знает протокольных буферов, gRPC потребует значительных затрат на наращивание. Если никто не знает преобразователи GraphQL, ожидайте месяц обучения до готовности к работе.

Распространенные ошибки, которых следует избегать

• Выбор GraphQL, потому что он кажется новым. GraphQL добавляет сложность преобразователя, запрос анализ затрат и смягчение последствий N+1. Если ваш API имеет 10 конечных точек CRUD с фиксированными формами, REST та же работа с меньшим количеством кода.
• Выбор gRPC для общедоступного API. Ваши пользователи не могут вызывать gRPC из браузера, из curl или с помощью инструмента с низким кодом. В любом случае вы в конечном итоге построите перед ним шлюз REST.
• Выбор REST для сложного графа данных. Если ваша фронтенд-команда запросит 5 новых «сводные» конечные точки за спринт, поскольку существующие возвращают слишком много или слишком мало данных, это признак того, что GraphQL снизит накладные расходы на координацию.
• Игнорирование опыта команды. Самый быстрый протокол для отправки — тот, который ваша команда уже знает. Команда, свободно владеющая REST и перешедшая на gRPC, потратит недели на разработку инструментов, прежде чем написание бизнес-логики.