REST против RPC: два подхода к проектированию API

Вы проектируете API для нового сервиса. Стоит ли моделировать его вокруг ресурсов с HTTP-глаголами или предоставить процедуры, которые клиенты вызывают напрямую? Это не просто выбор протокола — это фундаментальное решение о том, как вы думаете об интерфейсе вашей системы.

Проектирование API в стиле REST или RPC представляет два различных образа мышления, а не просто две технологии. Понимание того, когда каждый подход проявляет себя лучше всего (и когда их стоит комбинировать), избавит вас от архитектурных проблем в будущем.

Основное различие в подходах

REST мыслит ресурсами. У вас есть существительные (пользователи, заказы, продукты) и фиксированный набор глаголов (GET, PUT, DELETE). URL идентифицирует то, с чем вы работаете, а HTTP-метод указывает как.

RPC мыслит действиями. У вас есть процедуры (createUser, processPayment, generateReport), которые вы вызываете с аргументами. Фокус на том, что вы хотите сделать, а не на том, с чем вы работаете.

Ни один подход не является изначально лучше. Они хорошо решают разные задачи.

// REST: ресурсно-ориентированный
GET /users/123
PUT /users/123 { "name": "Alice" }

// RPC: действие-ориентированный  
POST /rpc/getUser { "id": 123 }
POST /rpc/updateUserName { "id": 123, "name": "Alice" }

Распространённые заблуждения, которые стоит развеять

REST — это не «просто JSON CRUD». Настоящий REST включает ограничения, такие как отсутствие состояния, кешируемость и слоистые системы. Большинство «REST API» на самом деле являются HTTP API с ресурсно-ориентированными URL — что нормально, но это не одно и то же.

RPC не устарел. Современные реализации, такие как gRPC и Connect, обеспечивают работу критически важной инфраструктуры в Google, Netflix и бесчисленных стартапах. gRPC работает поверх HTTP/2 и HTTP/3 со стандартной поддержкой маршрутизации в Kubernetes Gateway API.

HTTP API против RPC — это не бинарный выбор. Многие промышленные системы используют REST на границе (публичные API, браузерные клиенты) и RPC внутри (взаимодействие между сервисами). Этот гибридный паттерн становится всё более распространённым.

Практические компромиссы, которые действительно важны

Кеширование и HTTP-инструменты

Ресурсная модель REST естественным образом согласуется с HTTP-кешированием. Ответ GET /products/123 может кешироваться CDN, браузерами и прокси без какой-либо специальной настройки.

RPC обычно использует POST для всего, что HTTP-инфраструктура по умолчанию считает некешируемым. Вы можете сделать RPC кешируемым, но это требует явной проектной работы.

Типобезопасность и генерация кода

Современные RPC-фреймворки, такие как gRPC (с Protocol Buffers) и Connect, обеспечивают строгую типизацию и автоматическую генерацию клиентов. Вы определяете свой сервис один раз, затем генерируете клиенты для TypeScript, Go, Python и других языков.

У REST есть OpenAPI (сейчас версия 3.2, где 3.1 ввела полное согласование с JSON Schema), который предлагает аналогичную генерацию кода. Но типизация часто ощущается как надстройка, а не как нативная функция.

Потоковая передача и данные в реальном времени

gRPC нативно поддерживает двунаправленную потоковую передачу. REST требует обходных решений — Server-Sent Events, WebSockets или длинный опрос (long-polling).

Для браузерных клиентов RPC обычно работает через gRPC-Web, HTTP-дружественный протокол Connect или JSON-транскодирование. Это добавляет сложность, но позволяет использовать паттерны потоковой передачи, которые чистый REST не может обеспечить.

Обработка ошибок

REST API всё чаще принимают RFC 9457 (Problem Details) для стандартизированных ответов об ошибках. RPC-фреймворки имеют свои собственные модели ошибок — например, коды состояния gRPC.

Оба подхода работают. Ключ — в согласованности внутри вашей системы.

Когда что выбирать

Склоняйтесь к REST, когда:

• Создаёте публичные API, потребляемые неизвестными клиентами
• Кеширование критично для производительности
• Вы хотите максимальной совместимости с существующими HTTP-инструментами
• Ваши операции чётко соответствуют CRUD над ресурсами

Склоняйтесь к RPC, когда:

• Создаёте внутренние API для взаимодействия между сервисами
• Вам нужна потоковая или двунаправленная коммуникация
• Строгая типизация и генерация кода являются приоритетами
• Ваши операции действительно процедурные («перезагрузить сервер», «выполнить анализ»)

Используйте оба подхода, когда:

• У вас есть публичные API (REST) и внутренние микросервисы (RPC)
• Разные части вашей системы имеют разные требования

Гибридная реальность

Большинство современных паттернов архитектуры API не выбирают один подход исключительно. Типичная настройка может предоставлять REST API через API-шлюз для внешних потребителей, используя при этом gRPC между внутренними сервисами для производительности и типобезопасности.

Это не компромисс — это использование правильного инструмента для каждого контекста.

Заключение

Начните с ваших ограничений. Кто потребляет этот API? Какие операции он должен поддерживать? Насколько важно кеширование? Нужна ли вам потоковая передача?

REST против RPC — это не о том, что «лучше». Это о том, какой образ мышления — ресурсы или процедуры — лучше соответствует вашей задаче. Часто ответ — оба.

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

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..