На практике всё чаще смотрю на REST и JSON-RPC как на две разные оптики для одной задачи.

Обе рабочие, обе честные, просто подсвечивают систему с разных сторон.

В REST мне всегда нравилась ясность. Смотришь на endpoint - уже примерно понимаешь, что происходит, где ресурс, где изменение состояния, где граница ответственности.

В JSON-RPC цепляет другое ощущение. Как будто говоришь с системой на языке действий: не «вот тебе URL», а «сделай вот эту операцию».

И вот тут у меня обычно начинается самое интересное наблюдение.

Когда домен спокойный и «ресурсный», REST читается почти естественно. Когда домен состоит из команд, пересчётов, переоценок и оркестраций, JSON-RPC иногда звучит честнее, без попытки притвориться CRUD-миром.

🔵 REST: проще видеть форму системы. ⚪️ JSON-RPC: проще видеть намерение системы. 🔵 REST: удобнее жить внешним интеграциям. ⚪️ JSON-RPC: удобнее собирать сложные внутренние действия в единый формат.

Небольшой факт из спецификации: JSON-RPC 2.0 заметно взрослее 1.0. Появились именованные параметры, явное поле версии jsonrpc, логика с id стала прозрачной: есть id - запрос-ответ, нет id - «прими и выполни» без обратного сообщения, и более строгий ответ: либо result, либо error.

Поэтому мне всё меньше хочется воспринимать это как выбор «навсегда». Скорее как вопрос: что именно мы хотим сделать более прозрачным - структуру ресурсов или язык команд.

Возможно, зрелость как раз в том, чтобы не искать один «правильный» стиль и честно называть задачу тем инструментом, который ей подходит.

А у вас в проектах где больше трения: в форме endpoint-ов или в смысле самих бизнес-операций?