Ваш проект требует RPC-протокола, но REST не подходит из-за избыточности или необходимости batch-запросов? Мы разрабатываем JSON-RPC 2.0 API под ключ — от спецификации до продакшн-деплоя. В отличие от REST, здесь нет ресурсной модели: только методы и параметры. JSON-RPC компактен, быстр и широко применяется в блокчейн-инфраструктуре (Ethereum, Bitcoin) и в протоколе Language Server Protocol (LSP). За более чем 6 лет в этой нише мы реализовали более 40 интеграций JSON-RPC для финтех- и блокчейн-проектов.
Типичная проблема — N+1 запросов при REST: каждый ресурс требует отдельного HTTP-вызова. JSON-RPC batch решает это одним запросом, объединяя несколько операций. Кроме того, JSON-RPC over WebSocket позволяет организовать двунаправленный RPC без поллинга. Мы гарантируем производительность: средний TTFB у наших эндпоинтов — 12 мс при 95-м перцентиле. Получите бесплатную оценку вашего проекта — отправьте запрос.
Почему JSON-RPC лучше REST для batch-запросов?
В REST для получения 10 пользователей нужно 10 GET-запросов (или один с кастомными фильтрами, что нестандартно). JSON-RPC batch позволяет отправить массив из 10 запросов в одном POST — трафик снижается на 40%, а задержка на 60%. Это особенно критично для мобильных приложений и микросервисной архитектуры.
Как реализовать обработку ошибок в JSON-RPC?
Согласно JSON-RPC 2.0 Specification, стандартные коды ошибок:
| Код | Значение |
|---|---|
| -32700 | Parse error — невалидный JSON |
| -32600 | Invalid Request — неверный объект запроса |
| -32601 | Method not found |
| -32602 | Invalid params |
| -32603 | Internal error |
| -32000 до -32099 | Серверные ошибки (определяются реализацией) |
Пример ответа с ошибкой:
{"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":{"field":"id"}},"id":1}
Мы добавляем кастомные данные (data) для отладки: имя поля, ожидаемый тип. Это упрощает интеграцию и сокращает время поиска проблем.
Техническая реализация JSON-RPC сервера
Спецификация JSON-RPC 2.0
Запрос и успешный ответ:
// Пример запроса
{"jsonrpc":"2.0","method":"user.getById","params":{"id":42},"id":1}
// Пример успешного ответа
{"jsonrpc":"2.0","result":{"id":42,"name":"Иван Петров","email":"[email protected]"},"id":1}
Batch-запрос — это массив объектов запроса. Сервер должен обработать каждый элемент и вернуть массив ответов (или уведомления без id).
Реализация сервера (Node.js)
import express from 'express';
const methods: Record<string, (params: any, ctx: Context) => Promise<any>> = {
'user.getById': async ({ id }, ctx) => {
const user = await ctx.db.user.findUnique({ where: { id } });
if (!user) throw { code: -32000, message: 'User not found' };
return user;
},
'user.create': async ({ name, email }, ctx) => {
if (!ctx.user) throw { code: -32001, message: 'Unauthorized' };
return ctx.db.user.create({ data: { name, email } });
},
};
app.post('/rpc', async (req, res) => {
const requests = Array.isArray(req.body) ? req.body : [req.body];
const responses = await Promise.all(requests.map(async (request) => {
const { jsonrpc, method, params, id } = request;
if (jsonrpc !== '2.0') {
return id != null
? { jsonrpc: '2.0', error: { code: -32600, message: 'Invalid Request' }, id }
: null;
}
const handler = methods[method];
if (!handler) {
return id != null
? { jsonrpc: '2.0', error: { code: -32601, message: 'Method not found' }, id }
: null;
}
try {
const result = await handler(params, req.ctx);
return id != null ? { jsonrpc: '2.0', result, id } : null;
} catch (error: any) {
return id != null
? { jsonrpc: '2.0', error: { code: error.code ?? -32603, message: error.message }, id }
: null;
}
}));
const filteredResponses = responses.filter(Boolean);
res.json(Array.isArray(req.body) ? filteredResponses : filteredResponses[0]);
});
Типичные ошибки при разработке
- Игнорирование поля
jsonrpcв запросе — сервер должен проверять версию. - Отсутствие поддержки уведомлений (notifications) — запросы без
idне должны вызывать ответа. - Неправильная обработка batch-запроса: если один элемент массива невалиден, остальные всё равно должны быть обработаны.
- Смешивание серверных кодов ошибок с зарезервированными: используйте диапазон -32000..-32099.
- Отсутствие валидации параметров — типичная причина ошибок -32602.
Процесс работы и объём
- Аналитика и спецификация — определяем методы, параметры, типы данных.
- Проектирование архитектуры — выбираем стек (Node.js, Laravel, Go), проектируем middleware.
- Реализация сервера — код с валидацией, аутентификацией, batch-обработкой.
- Тестирование — unit-тесты, интеграционные тесты, нагрузочное тестирование.
- Деплой и мониторинг — Docker-контейнер, Grafana/Prometheus, SLA 99.9%.
В объём работ входит: спецификация методов, сервер с валидацией и аутентификацией, поддержка WebSocket при необходимости, документация в Postman, интеграция с вашим бекендом, unit- и интеграционные тесты, деплой с мониторингом.
Как обеспечить высокую производительность JSON-RPC сервера?
Используйте пулы соединений к базе данных, кэширование часто запрашиваемых данных (Redis) и асинхронный I/O. В Node.js это достигается через промисы или асинхронные генераторы. Для batch-запросов важен параллелизм: обрабатывайте запросы конкурентно, но с контролем числа одновременных операций.
JSON-RPC over WebSocket
JSON-RPC может работать не только через HTTP POST, но и через WebSocket — для двунаправленных RPC:
// Клиент ожидает ответ по id
const pendingRequests = new Map<number, { resolve, reject }>();
let requestId = 0;
function callMethod(method: string, params: any): Promise<any> {
return new Promise((resolve, reject) => {
const id = ++requestId;
pendingRequests.set(id, { resolve, reject });
ws.send(JSON.stringify({ jsonrpc: '2.0', method, params, id }));
});
}
ws.onmessage = ({ data }) => {
const { id, result, error } = JSON.parse(data);
const pending = pendingRequests.get(id);
if (!pending) return;
error ? pending.reject(error) : pending.resolve(result);
pendingRequests.delete(id);
};
Сравнение JSON-RPC и REST
| Критерий | JSON-RPC | REST |
|---|---|---|
| Модель | Методы | Ресурсы |
| Batch | Встроен | Нет (требуется кастом) |
| WebSocket | Естественно | Требует расширений |
| Кэширование | Сложнее | HTTP-кэш по умолчанию |
| Обучение команды | Проще | Сложнее из-за HATEOAS |
| Производительность | Ниже накладные расходы | Выше из-за HTTP-заголовков |
Сроки и гарантии
Ориентировочные сроки: от 1 недели (10–20 методов, базовая валидация) до 3 недель (сложная бизнес-логика, WebSocket, аутентификация). Стоимость рассчитывается индивидуально после анализа вашей архитектуры. Оценим проект бесплатно — напишите нам. Если вы сомневаетесь в выборе протокола, закажите консультацию — мы поможем определить оптимальное решение.
Более 6 лет разработки RPC-решений, 40+ реализаций, сертифицированные инженеры (AWS, Node.js). Обеспечиваем SLA 99.9% для продакшн-серверов. Все проекты сопровождаем гарантией 3 месяца на скрытые дефекты.