REST, gRPC и GraphQL не конкурируют за одну корону; каждый стиль выигрывает в своём сочетании клиентов, контрактов и отказов.
Для реального проектирования глава помогает увидеть, как аудитория API, форма контракта, допустимая задержка, кэширование и обратная совместимость должны определять выбор сильнее, чем личные предпочтения команды.
Для интервью и инженерных разборов она полезна тем, что переводит разговор с синтаксиса API на поведение удалённого вызова: тайм-ауты, повторные попытки, резервный сценарий и наблюдаемость.
Практическая польза главы
Практика проектирования
Подбирайте REST, gRPC или GraphQL под аудиторию API, контракт и допустимую задержку.
Качество решений
Описывайте модель ошибок, версионирование и обратную совместимость как часть API-дизайна.
Аргументация на интервью
Сравнивайте подходы через простоту клиента, наблюдаемость, кэширование и цену поддержки.
Анализ отказов
Планируйте частичные отказы: тайм-ауты, повторные попытки, резервный сценарий и автоматический размыкатель.
Источник
Remote procedure call
Откуда пришла идея удалённого вызова процедуры и почему сеть нельзя прятать полностью.
Зачем сравнивать стили удалённых вызовов
В этой главе , REST, gRPC и GraphQL — это разные способы оформить один и тот же сетевой диалог. Спор о том, какой стиль выглядит современнее, обычно бесполезен. Вопрос в другом: где проще держать , задержку, совместимость и предсказуемое поведение при отказах, и во что обойдётся неверный выбор спустя год. Эта глава — про синхронные стили вызова; более широкую картину синхронного и асинхронного взаимодействия между сервисами (очереди, событийные потоки, публикация и подписка) разбирает глава «Паттерны межсервисной коммуникации».
Стандарт
OpenAPI Specification
Официальный формат описания REST-контрактов, схем данных, ошибок и авторизации.
Базовая модель удалённого вызова
Любой такой вызов начинается с : клиент формирует запрос, сервер выполняет работу и возвращает ответ. В этот зазор между сторонами попадает всё, что отличает локальный вызов от сетевого, — , сетевые задержки, тайм-ауты и риск частичного отказа. Поэтому протокол нельзя выбрать в отрыве от архитектуры: вместе с ним вы выбираете контракт, модель ошибок и эксплуатационные ограничения.
Источник
GraphQL Learn
Официальное введение в схему, запросы, резолверы и практики GraphQL.
REST, gRPC и GraphQL: как устроены подходы
Переключайте режимы: диаграмма показывает, что меняется в форме запроса, ответа и контракта между сторонами.
Как работают удалённые вызовы
Выберите подход, чтобы увидеть, как строится запрос и ответ
Запрос и ответ
Ключевые свойства
- Абстракция вызова процедуры
- Фокус на методах, а не ресурсах
- Чаще всего бинарная сериализация
Что важно помнить
Сравнение по ключевым критериям
| Критерий | REST | gRPC | GraphQL |
|---|---|---|---|
| Модель контракта | Ресурсы протокола HTTP и через OpenAPI. | в схемах Protocol Buffers и генерация кода. | Единая и запросы клиента к нужным полям. |
| Формат данных | Обычно JSON: читаемо, но часто больше. | : компактнее и дешевле для CPU и сети. | Чаще JSON; размер ответа зависит от формы запроса и политики кэширования. |
| Задержка и пропускная способность | Надёжный выбор для публичных API и партнёрских интеграций. | Часто лучше подходит для внутренних вызовов с жёстким . | Удобен для клиента, но может проигрывать из-за резолверов. |
| Эволюция API | через URI, заголовки или новый ресурс. | Эволюция полей по правилам Protocol Buffers: номера полей, `reserved`, совместимые enum. | через устаревшие поля, расширение типов и типизированный контракт. |
| Кэширование | Сильные встроенные механики кэширования протокола HTTP и промежуточных прокси. | Кэш чаще строят на уровне клиента, шлюза или прикладного слоя. | Нужна явная стратегия: , нормализованный кэш и . |
| Где чаще подходит | Внешние API, партнёрские интеграции, простой вход для разных стеков. | Внутренние сервисы, строгие контракты, потоковые вызовы и высокая нагрузка. | , сложные UI и несколько клиентских платформ. |
Контракты и эволюция API
REST и OpenAPI
OpenAPI фиксирует точки входа, параметры, схемы ответов, ошибки и правила авторизации. Это снижает риск для внешних клиентов.
gRPC и схемы Protocol Buffers
Схема Protocol Buffers задаёт интерфейс, сообщения и сервисы. Команда получает строгий контракт, генерацию кода и понятные правила .
GraphQL и схема
Здесь схема описывает типы, поля и связи, а клиент сам решает, что запросить. За эту гибкость платят лимитами глубины запроса, бюджетами для и наблюдаемостью — иначе один запрос способен положить нижестоящие сервисы.
Как выбирать в реальных сценариях
Публичное API для партнёров
Здесь обычно выигрывает REST: документация, ручное тестирование, кэширование и интеграция из любого стека достаются почти бесплатно, а интегратор на той стороне может не знать про ваши инструменты.
Внутренний сервисный контур
Внутри периметра картина меняется: бинарный формат, строгий контракт и низкая задержка gRPC важнее, чем удобство ручного вызова из браузера, — этим удобством можно пожертвовать.
Мобильный и web-клиент
GraphQL помогает уменьшить и , если схема и резолверы управляются дисциплинированно.
Смешанная платформа
На практике стили чаще сочетают, а не выбирают один: REST наружу, gRPC между сервисами, GraphQL или бэкенд для фронтенда (BFF) как фасад для клиентских приложений. Цена такого подхода — несколько контрактов и моделей ошибок, которые приходится держать в голове одновременно.
Частые антипаттерны
Практические рекомендации
Что важно запомнить
REST, gRPC и GraphQL не конкурируют за один и тот же сценарий. REST обычно выигрывает там, где важны понятность внешнего контракта и совместимость. gRPC силён во внутренних сервисных вызовах со строгой схемой. GraphQL полезен как клиентский фасад, если команда готова управлять сложностью схемы и резолверов.
Источники
- Roy Fielding: REST dissertation - первоисточник ограничений REST и архитектурного стиля.
- gRPC Documentation - официальное введение в сервисы, контракты и типы удалённых вызовов процедур.
- GraphQL Learn - официальный материал по схеме, запросам, мутациям и практикам производительности.
- OpenAPI Specification - каноничный стандарт описания REST-контрактов и схем данных.
Связанные главы
- Паттерны межсервисной коммуникации - Продолжение темы: синхронные и асинхронные вызовы, тайм-ауты, повторные попытки и обратное давление.
- Customer-friendly API: удобное API для клиентов - Как выбирать между бэкендом для фронтенда (BFF), REST и GraphQL с точки зрения задач клиента, а не внутренней структуры сервера.
- API Design Patterns (short summary) - Паттерны долгоживущих API-контрактов, совместимости и безопасной эволюции интерфейсов.
- Learning GraphQL (short summary) - Глубже про схему GraphQL, резолверы, типизацию и организацию API вокруг клиентских сценариев.
- Протокол HTTP - База для REST, GraphQL поверх протокола HTTP и gRPC-over-HTTP/2: методы, заголовки, кэширование и статус-коды.
- Обнаружение сервисов - Как клиенты находят живые экземпляры сервисов, когда удалённые вызовы идут в динамическом кластере.
- API Gateway - Где размещать трансляцию протоколов, авторизацию, ограничение частоты запросов и единый вход для клиентов.
- Зачем нужны распределённые системы и консистентность - Почему любой удалённый вызов нужно рассматривать через задержки, отказы, доступность и согласованность.