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. | в `.proto` и генерация кода. | Единая и запросы клиента к нужным полям. |
| Формат данных | Обычно JSON: читаемо, но часто больше. | : компактнее и дешевле для CPU и сети. | Чаще JSON; размер ответа зависит от формы запроса и политики кэширования. |
| Задержка и пропускная способность | Надёжный выбор для публичных API и партнёрских интеграций. | Часто лучше подходит для внутренних вызовов с жёстким . | Удобен для клиента, но может проигрывать из-за резолверов. |
| Эволюция API | через URI, заголовки или новый ресурс. | Эволюция полей по правилам Protocol Buffers: номера полей, `reserved`, совместимые enum. | через устаревшие поля, расширение типов и типизированный контракт. |
| Кэширование | Сильные встроенные механики HTTP-кэша и промежуточных прокси. | Кэш чаще строят на уровне клиента, шлюза или прикладного слоя. | Нужна явная стратегия: , нормализованный кэш и . |
| Где чаще подходит | Внешние API, партнёрские интеграции, простой вход для разных стеков. | Внутренние сервисы, строгие контракты, потоковые вызовы и высокая нагрузка. | , сложные UI и несколько клиентских платформ. |
Контракты и эволюция API
REST и OpenAPI
OpenAPI фиксирует точки входа, параметры, схемы ответов, ошибки и правила авторизации. Это снижает риск для внешних клиентов.
gRPC и .proto
`.proto` задаёт интерфейс, сообщения и сервисы. Команда получает строгий контракт, генерацию кода и понятные правила .
GraphQL и схема
Схема описывает типы, поля и связи. Но гибкость клиента требует лимитов глубины, бюджетов для и наблюдаемости.
Как выбирать в реальных сценариях
Публичное API для партнёров
Чаще выбирают REST: проще документация, тестирование вручную, кэширование и интеграция с разными языками и платформами.
Внутренний сервисный контур
Часто подходит gRPC: бинарный формат, строгий контракт и низкая задержка важнее, чем удобство ручного вызова из браузера.
Мобильный и web-клиент
GraphQL помогает уменьшить и , если схема и резолверы управляются дисциплинированно.
Смешанная платформа
Частый вариант: REST наружу, gRPC между сервисами, GraphQL или BFF как фасад для клиентских приложений.
Частые антипаттерны
Практические рекомендации
Что важно запомнить
REST, gRPC и GraphQL не конкурируют за один и тот же сценарий. REST обычно выигрывает там, где важны понятность внешнего контракта и совместимость. gRPC силён во внутренних сервисных вызовах со строгой схемой. GraphQL полезен как клиентский фасад, если команда готова управлять сложностью схемы и резолверов.
Источники
- Roy Fielding: REST dissertation - первоисточник ограничений REST и архитектурного стиля.
- gRPC Documentation - официальное введение в сервисы, контракты и типы RPC-вызовов.
- 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: методы, заголовки, кэширование и статус-коды.
- Обнаружение сервисов (service discovery) - Как клиенты находят живые экземпляры сервисов, когда удалённые вызовы идут в динамическом кластере.
- API Gateway - Где размещать трансляцию протоколов, авторизацию, ограничение частоты запросов и единый вход для клиентов.
- Зачем нужны распределённые системы и консистентность - Почему любой удалённый вызов нужно рассматривать через задержки, отказы, доступность и согласованность.