Задача: выбрать способ передачи сообщений в API для сервисной архитектуры
Обычно выбор делается из двух решений:
- REST
- gRPC
это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор:
- использование HTTP/2
- обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными)
- кодогенерация
- RPC ориентированность (в том числе stream-based)
Со стороны REST кроме требований самой архитектуры обычно выделяют:
- простота
- текстовый формат обмена (удобство)
Таким образом gRPC отлично подходит для организации взаимодействия внутри сервисной (микросервисной) архитектуры, а для внешних API хорошо подходит REST стиль.
Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами.
SOER | PRO | Boosty
Обычно выбор делается из двух решений:
- REST
- gRPC
это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор:
- использование HTTP/2
- обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными)
- кодогенерация
- RPC ориентированность (в том числе stream-based)
Со стороны REST кроме требований самой архитектуры обычно выделяют:
- простота
- текстовый формат обмена (удобство)
Таким образом gRPC отлично подходит для организации взаимодействия внутри сервисной (микросервисной) архитектуры, а для внешних API хорошо подходит REST стиль.
Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами.
SOER | PRO | Boosty