Выбор между RPC и REST редко про вкус; обычно он про форму контракта, эволюцию клиента и цену сетевого вызова.
Для реального проектирования глава помогает увидеть, как latency targets, формат интеграции, error contract, versioning и backward compatibility должны влиять на выбор подхода сильнее, чем общая мода на JSON или protobuf.
Для интервью и инженерных разборов она полезна тем, что помогает обсуждать удаленный вызов через partial failure handling, fallback, hedging и circuit breaker policy, а не только через синтаксис API.
Практическая польза главы
Практика проектирования
Выбирайте RPC/REST стиль под domain latency targets и формат интеграции.
Качество решений
Описывайте error contract, versioning и backward-compatibility как часть API-дизайна.
Interview articulation
Сравнивайте варианты через простоту клиента, observability и стоимость поддержки.
Failure framing
Планируйте partial failure handling: fallback, hedging и circuit-breaker policy.
Источник
Remote procedure call
Определение RPC и ключевые свойства.
RPC, REST и gRPC — это разные подходы к удалённым вызовам. Они решают одну задачу: передать запрос через сеть и получить результат, но отличаются стилем интерфейса, уровнем формализации и типичными сценариями применения.
Источник
REST
Архитектурный стиль, основные ограничения и свойства.
Визуализация работы подходов
Выберите подход и посмотрите, как формируется запрос, ответ и контракт между сторонами.
Как работают удалённые вызовы
Выберите подход, чтобы увидеть, как строится запрос и ответ
Запрос и ответ
Ключевые свойства
- Прозрачность вызова процедуры
- Фокус на методах, а не ресурсах
- Чаще всего бинарная сериализация
Что важно помнить
Источник
gRPC basics
Сервисы, proto-контракты и типы RPC вызовов.
Что у них общего
- Работают по модели клиент-сервер и передают запросы по сети.
- Используют сериализацию данных и контракт между клиентом и сервером.
- Требуют описания ошибок, таймаутов и ретраев.
Чем отличаются
RPC
- Фокус на вызове метода, как локальной функции.
- Удобно для внутренних сервисов и бинарных протоколов.
- Часто сильнее связаны клиент и сервер.
REST
- Фокус на ресурсах и HTTP методах.
- Статeless и хорошо кэшируется.
- Лучше для публичных API и интеграций.
gRPC
- Контракт описывается в .proto и генерирует код.
- Поддерживает streaming вызовы.
- Хорошо подходит для микросервисов.
Стандарт
OpenAPI Specification
Официальный формат описания REST-контракта: endpoints, схемы данных, ошибки и security.
OpenAPI как контракт в REST
Зачем нужен OpenAPI
- Фиксирует контракт API в машиночитаемом виде, а не в «живой документации на словах».
- Позволяет генерировать SDK/клиенты, документацию и заглушки для тестирования.
- Упрощает контроль breaking changes через diff и contract checks в CI.
- Снижает рассинхрон между backend, frontend и интеграторами.
Что описываем в контракте
- Пути и методы (`/users`, `GET/POST`), параметры, форматы payload.
- Схемы запросов/ответов, обязательные поля и ограничения валидации.
- Ошибки (`4xx/5xx`) и единый формат error response.
- Security-схемы (JWT, API key, OAuth2) и требования к авторизации.
Пример (упрощённо)
openapi: 3.1.0
paths:
/users/{id}:
get:
responses:
"200":
description: User profile
content:
application/json:
schema:
$ref: "#/components/schemas/User"
components:
schemas:
User:
type: object
required: [id, email]
properties:
id: { type: string }
email: { type: string, format: email }Когда что выбирать
- RPC удобен для внутренних сервисов, где важна скорость и компактные контракты.
- REST подходит для публичных API и интеграций, где важны кэширование и совместимость.
- gRPC хорош для микросервисов, когда нужен строгий контракт и streaming.
Связанные главы
- HTTP протокол - как REST и gRPC-over-HTTP/2 реализуются на прикладном уровне и какие накладные расходы они несут.
- TCP протокол - транспортная база для надёжных RPC/REST вызовов: handshake, retransmit, flow/congestion control.
- UDP протокол - контрастный transport-подход для latency-critical сценариев без встроенной гарантии доставки.
- Паттерны межсервисной коммуникации - системный выбор между sync/async взаимодействием, retries и backpressure на уровне сервисов.
- Service Discovery - как клиенты находят живые endpoint-ы сервисов при динамическом масштабировании и failover.
- API Gateway - протокол-трансляция, auth, rate limiting и единая точка входа для внешних и внутренних клиентов.
- API Design Patterns (short summary) - контрактные паттерны API и эволюция изменений без поломки интеграций.
- Зачем нужны распределённые системы и консистентность - переход от выбора протокола к системным компромиссам latency, availability и consistency.