Ответ
Плюсы:
- Простота и лёгкость: Легковесный протокол на основе JSON, понятный для чтения и реализации.
- Чёткая структура: Запросы и ответы имеют строгую структуру (
jsonrpc,method,params,id,result/error), что упрощает парсинг. - Широкая поддержка: Реализации есть практически для всех языков программирования благодаря стандартным библиотекам работы с JSON.
- Пакетные операции (batching): Возможность отправки нескольких запросов в одном HTTP-вызове, что повышает эффективность для асинхронных сценариев.
- Независимость от транспорта: Может работать поверх HTTP, WebSockets, TCP и т.д.
Минусы:
- Отсутствие стандартов для инфраструктуры: Нет встроенных механизмов для авторизации, кеширования, версионирования API или документации (в отличие от REST с OpenAPI).
- Слабая типизация: Параметры и результаты — это JSON-структуры, что может приводить к ошибкам типов на этапе выполнения; требуется дополнительная валидация.
- Менее информативные ошибки: Ошибки передаются в собственном формате, а не через стандартные HTTP-статусы, что может усложнить интеграцию с мониторингом и прокси-серверами.
- Сложность с кешированием: Запросы, как правило, используют POST, что затрудняет кеширование на уровне HTTP по сравнению с GET-запросами в REST.
Пример запроса и ответа (JSON-RPC 2.0):
// Запрос
{
"jsonrpc": "2.0",
"method": "calculateSum",
"params": {"a": 5, "b": 3},
"id": 1
}
// Успешный ответ
{
"jsonrpc": "2.0",
"result": 8,
"id": 1
}
// Ответ с ошибкой
{
"jsonrpc": "2.0",
"error": {
"code": -32601,
"message": "Method not found"
},
"id": 1
}Ответ 18+ 🔞
А, ну это же про JSON-RPC, классика жанра! Слушай, давай разберём, что тут к чему, без всякой воды. Просто как есть.
Что хорошего, или почему его до сих пор юзают:
Ну, во-первых, простота до безобразия. Всё на JSON, ёпта. Открыл глаза — и уже понятно, что к чему. Никаких тебе сложных заголовков, никаких извращений с маршрутами. Написал method — и сервер уже знает, что делать. Вротберунчик, и всё работает.
Во-вторых, структура чёткая, как у швейцарских часов. Всегда есть jsonrpc, method, params и id. Ответ — result или error. Никаких сюрпризов, всё предсказуемо. Парсить это — одно удовольствие, а не манда с ушами, как некоторые REST-апишки с их вложенными объектами в query-параметрах.
В-третьих, поддержка везде. Хоть на PHP, хоть на Python, хоть на Brainfuck (наверное). JSON везде есть, библиотеки — тоже. Не надо изобретать велосипед.
И главный козырь — пакетные запросы (batching). Это когда ты можешь в один HTTP-вызов запихнуть кучу команд. Представь, тебе надо десять разных данных получить — ты не делаешь десять запросов, ты один делаешь. Овердохуища экономии на сетевых задержках, особенно если связь так себе.
И ещё — ему похуй на транспорт. HTTP, WebSockets, TCP, хоть почтовыми голубями передавай — лишь бы JSON долетел. Универсальная штука.
А теперь про минусы, потому что без них никуда:
Первый и главный — инфраструктуры, блядь, ноль. Нет тут тебе встроенной авторизации, кеширования, версионирования или красивой документации, как в REST с его OpenAPI. Всё это приходится прикручивать сверху, самому. Доверия ебать ноль к тому, что два разных разработчика сделают это одинаково.
Второе — типизация слабенькая, как у студента после сессии. Параметры — это просто JSON-объект. Передал строку вместо числа? Получи ошибку в рантайме, а не на этапе компиляции. Приходится всё валидировать вручную, терпения ноль ебать.
Третье — ошибки какие-то свои, кастомные. В REST хотя бы понятно: 404 — не найдено, 500 — сервер сломался. А тут своя система кодов, и мониторингу, и всяким проксям под него подстраиваться надо. Не всегда удобно.
И наконец, кеширование — боль. Запросы почти всегда идут POST-ом, а кешировать POST — это хитрая жопа. В REST с GET-запросами всё проще. Тут либо свой кеш городить, либо забыть про него.
Ну и чтобы совсем понятно было, вот как это выглядит в жизни:
// Вот мы шлём запрос, типа "посчитай сумму, дружок"
{
"jsonrpc": "2.0",
"method": "calculateSum",
"params": {"a": 5, "b": 3},
"id": 1
}
// Сервер, если всё ок, отвечает так
{
"jsonrpc": "2.0",
"result": 8,
"id": 1
}
// А если он метод не нашёл (или мы обдолбались и опечатались)
{
"jsonrpc": "2.0",
"error": {
"code": -32601,
"message": "Method not found"
},
"id": 1
}Вот и вся магия. Инструмент как инструмент — где-то ебёт, где-то прёт. Для внутреннего общения между сервисами — часто то, что надо. Для публичного API — уже надо думать, готовы ли вы сами всю инфраструктуру лепить.