REST VS gRPC: ДВА СПОСОБА ЗАКАЗАТЬ ПИЦЦУ

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

Представим, что мы разрабатываем мобильное приложение для сети пиццерий. Приложение — это клиент. Сервер — место, где хранится меню, создаются заказы, назначаются курьеры и рассчитывается время доставки.

Перед нами встает вопрос: как приложению общаться с сервером? REST или gRPC?

В REST все строится вокруг ресурсов. Для нашей пиццерии это могут быть:
⬛ /pizzas
⬛ /orders
⬛ /drinks

Если приложению нужно получить список пицц, оно отправляет запрос:
GET /pizzas

Если создать заказ:
POST /orders

Обычно данные передаются в формате JSON.

{
  "order_id": 1,
  "pizza_name": "Pepperoni"
}

JSON легко читать человеку, поэтому REST стал стандартом для большинства публичных API.

Над ресурсами выполняются привычные CRUD-операции: POST, GET, PUT / PATCH, DELETE. Подход простой, понятный и очень распространенный.

gRPC работает иначе. Вместо обращения к ресурсам клиент "вызывает" методы сервера — почти как обычные функции в коде.

Для нашей пиццерии это может выглядеть так:
⬛ GetAllPizzas()
⬛ CreateOrder()
⬛ GetOrderStatus()

Получается примерно такой диалог:
⬛ Покажи все пиццы. → GetAllPizzas()
⬛ Создай заказ. → CreateOrder()

Одно из главных отличий gRPC — использование Protocol Buffers (Protobuf). Вместо того чтобы просто договориться о формате JSON, разработчики заранее описывают контракт API.

message Pizza {
  int32 id = 1;
  string name = 2;
}

По этому описанию автоматически генерируется код для клиента и сервера на разных языках программирования.

В REST строгой схемы обычно нет. Чаще команды договариваются о структуре JSON через документацию или просто следуют внутренним соглашениям.

Почему gRPC часто быстрее?
REST обычно передает текстовый JSON, а gRPC — бинарный формат Protobuf.

Бинарные сообщения занимают меньше места, быстрее сериализуются и требуют меньше ресурсов на обработку. Поэтому при интенсивном обмене данными между сервисами gRPC нередко выигрывает по производительности.

Что происходит, если API нужно изменить?
Представим, что пиццерия решила добавить калорийность.

message Pizza {
  int32 id = 1;
  string name = 2;
  int32 calories = 3;
}

Старые клиенты просто проигнорируют новое поле и продолжат работать.

Protobuf изначально проектировался так, чтобы контракты можно было безопасно развивать.

В REST обратную совместимость тоже можно обеспечить, но здесь гораздо больше зависит от дисциплины команды и правил проектирования API.

Что выбрать?
Если вы разрабатываете публичный API для сайта или мобильного приложения, REST чаще всего оказывается самым простым и понятным вариантом.

Если же вы строите систему из множества микросервисов, где важны производительность, строгие контракты, стоит посмотреть в сторону gRPC.

Запомнить разницу можно очень просто:
REST — работа с ресурсами (/pizzas, /orders, /drinks).
gRPC — вызов операций (GetAllPizzas(), CreateOrder(), GetOrderStatus()).

И самое интересное: в современных системах эти подходы отлично сосуществуют. REST часто используют для внешних клиентов, а gRPC — для общения внутренних сервисов.

#бабанюра_программирует