От REST к RPC

В монолитном приложении функции вызывают друг друга просто обращаясь к адресам в оперативной памяти. В микросервисах нам нужно научить одну программу (написанную, например, на Go) вызывать функцию в другой программе (написанной на Java), которая крутится на сервере в другом дата-центре.

Для этого придуман RPC (Remote Procedure Call — Удалённый вызов процедур). Это концепция, при которой вызов удаленной функции по сети выглядит для программиста точно так же, как вызов обычной локальной функции.

Сравнивать их напрямую не совсем корректно, так как RPC — это широкая концепция, а REST — архитектурный стиль. Но на практике разница сводится к подходу проектирования API:

• REST (Resource-Oriented): Сфокусирован на существительных (ресурсах). Мы делаем POST /users, GET /users/1. Глаголы ограничены HTTP-методами (GET, POST, PUT, DELETE).
• RPC (Action-Oriented): Сфокусирован на глаголах (действиях). Мы буквально вызываем функции: CreateUser(), BanUserAndSendEmail(). И нам не так важно, какой HTTP-метод используется под капотом (часто всё гоняется через POST).

RPC — это общий термин. Под ним скрывается множество технологий:

1. Бинарные RPC-фреймворки: gRPC (от Google), Apache Thrift (от Facebook). Это современные стандарты для систем.
2. Текстовые протоколы: JSON-RPC, XML-RPC (устарел), SOAP.
3. WebSockets: Использование протокола WAMP для двунаправленного RPC в реальном времени (например, в браузерных играх).

Далее мы подробно разберем самый популярный фреймворк — gRPC.