JSON-RPC 2.0 как альтернатива REST API. Почему стоит использовать его?
BACKEND
1. Почему REST API не так хорош для микросервисов, как мы думаем.
REST API слишком сильно связан с транспортом (HTTP), из-за этого у микросервисов появляются накладные расходы, снижается производительность и надёжность, усложняется покрытие тестами. Также REST API требует дополнительных ресурсов разработки, в отличие от RPC (Remote Procedure Call).
2. Допилить REST API или перейти на JSON-RPC?
Фактически приходится всё больше и больше дорабатывать REST API, а в итоге даже влезать в конечные клиентские проекты. Но ведь это уже не классический REST API!
3.Переход на JSON-RPC 2.0.
Протокол надёжный и не привязан к транспорту, поэтому лишен таких проблем. После перехода получаем увеличение быстродействия микросервисов более чем в 2 раза, используя брокеры сообщений, вместо HTTP.
4. Сокращаем время на разработку API.
Идеология RPC подразумевает использование существующих классов, поэтому не требуется практически никакой работы по интеграции с текущим проектом – просто подключаем нужные классы, и публичные методы класса сразу становятся доступны для API. Рассмотрим, как JSON RPC по сравнению с классическим REST API сокращает время на разработку API большее чем в 2 раза на примере FastAPI и в 4 раза на примере Dango.
5. Нативная идемпотентность и версионность запросов к API.
Дополнительный бонус, когда есть множество клиентов (веб, iOS, Android, микросервисы), на которых могут быть разные версии клиентов.
6. Особенности работы со спецификацией OpenRPC.
Есть отличия от OpenAPI, но в целом можно сконвертировать, и тогда получается использовать генераторы клиентов REST.
7. Собственный генератор документации и генератор клиента.
Кейс про генератор из OpenRPC документации на ReactJS и генератор клиента для Python и Typescript. В результате сократилось время на интеграцию API для существующих проектов почти в 2 раза.
REST API слишком сильно связан с транспортом (HTTP), из-за этого у микросервисов появляются накладные расходы, снижается производительность и надёжность, усложняется покрытие тестами. Также REST API требует дополнительных ресурсов разработки, в отличие от RPC (Remote Procedure Call).
2. Допилить REST API или перейти на JSON-RPC?
Фактически приходится всё больше и больше дорабатывать REST API, а в итоге даже влезать в конечные клиентские проекты. Но ведь это уже не классический REST API!
3.Переход на JSON-RPC 2.0.
Протокол надёжный и не привязан к транспорту, поэтому лишен таких проблем. После перехода получаем увеличение быстродействия микросервисов более чем в 2 раза, используя брокеры сообщений, вместо HTTP.
4. Сокращаем время на разработку API.
Идеология RPC подразумевает использование существующих классов, поэтому не требуется практически никакой работы по интеграции с текущим проектом – просто подключаем нужные классы, и публичные методы класса сразу становятся доступны для API. Рассмотрим, как JSON RPC по сравнению с классическим REST API сокращает время на разработку API большее чем в 2 раза на примере FastAPI и в 4 раза на примере Dango.
5. Нативная идемпотентность и версионность запросов к API.
Дополнительный бонус, когда есть множество клиентов (веб, iOS, Android, микросервисы), на которых могут быть разные версии клиентов.
6. Особенности работы со спецификацией OpenRPC.
Есть отличия от OpenAPI, но в целом можно сконвертировать, и тогда получается использовать генераторы клиентов REST.
7. Собственный генератор документации и генератор клиента.
Кейс про генератор из OpenRPC документации на ReactJS и генератор клиента для Python и Typescript. В результате сократилось время на интеграцию API для существующих проектов почти в 2 раза.
О СПИКЕРЕ
Руковожу отделом исследований и разработок в хостинг-провайдере SpaceWeb более 6 лет. Ранее занимал должность IT-директора в крупных российских веб-студиях и интернет-магазинах. Участвовал в разработке искусственного интеллекта совместно с кафедрой математической лингвистики СПбГУ.
Общий стаж в IT-сфере более 20 лет.
Стэк технологий разработки: Python, PHP, JavaScript, Go, C#, Swift, Kotlin.
Сертификаты: PMBoK, Python, JavaScript, PHP
Общий стаж в IT-сфере более 20 лет.
Стэк технологий разработки: Python, PHP, JavaScript, Go, C#, Swift, Kotlin.
Сертификаты: PMBoK, Python, JavaScript, PHP
MIDDLE
Виталий Киреев
SpaceWeb, Санкт-Петербург
Руководитель отдела исследований и разработок
Руководитель отдела исследований и разработок