From my experience JSON-RPC is rarely/ever used. It was one of the early things I implemented back in the days for CppCMS.
From the server side for example you want to run behind server specific communication, usually http but it can also be fastcgi, scgi - that is why middle-layer of http
Nowadays a much more common interface that is being used between client/server and services in general is REST (or its OpenAPI implementation). Also I'd recommend implementing it behind some HTTP/HTTPs implementation rather that over plain socket. From user perspective there should be no difference weather you communicate over SSL or not. Over HTTP/1.1, HTTP/2.0 or others. protocol implementation is necessary - even for more things like authentication, cookies and more. Because when you run some RPC request you need some security layer. This is usually handled by the library than handles HTTP itself (or its derivatives). I don't mean to discourage you but just to show the dimension of the problem. And of course consider that other methods are way more common than JSON-RPC. Artyom On Wed, Apr 10, 2024 at 10:23 PM Quentin Chateau via Boost < boost@lists.boost.org> wrote:
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/ ) spec with customizable serialization.
It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable.