Задача: выбрать способ передачи сообщений в API для сервисной архитектуры

Обычно выбор делается из двух решений:
- REST
- gRPC

это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор:

- использование HTTP/2
- обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными)
- кодогенерация
- RPC ориентированность (в том числе stream-based)

Со стороны REST кроме требований самой архитектуры обычно выделяют:
- простота
- текстовый формат обмена (удобство)

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

Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами.

SOER | PRO | Boosty