Ответ
REST и gRPC — это архитектурные стили для построения API, но с фундаментально разными подходами.
| Аспект | REST (обычно поверх HTTP/1.1) | gRPC (поверх HTTP/2) |
|---|---|---|
| Контракт | Неформальный, описан в документации (OpenAPI/Swagger). | Строгий, определяется в .proto-файлах. |
| Формат данных | Текстовый (JSON, XML). Человекочитаемый, но объёмный. | Бинарный (Protocol Buffers). Компактный и быстрый. |
| Парадигма | Ресурсо-ориентированная (CRUD над сущностями). | Удалённый вызов процедур (RPC). Клиент вызывает методы на сервере. |
| Производительность | Ниже из-за текстового формата и необходимости парсинга. | Высокая за счёт бинарного формата и встроенной потоковой передачи. |
| Потоковая передача | Эмулируется (WebSockets, Server-Sent Events). | Нативная поддержка однонаправленных и двунаправленных потоков. |
Пример контракта и вызова
REST (HTTP + JSON):
GET /api/v1/users/123
Accept: application/json{"id": 123, "name": "Alice", "email": "alice@example.com"}gRPC (.proto файл + вызов):
service UserService {
rpc GetUser (GetUserRequest) returns (User);
}
message GetUserRequest { int32 id = 1; }
message User {
int32 id = 1;
string name = 2;
string email = 3;
}// Клиентский код
var user = await client.GetUserAsync(new GetUserRequest { Id = 123 });Когда что выбирать:
- REST: Публичные API, веб-приложения, когда нужна простота, человекочитаемость и кэширование на уровне HTTP.
- gRPC: Внутренняя микросервисная коммуникация, среды с высокими требованиями к производительности и задержкам (например, мобильные приложения, системы реального времени), когда важна строгая типизация и потоковая передача.
