Le 2024-04-11 16:20, Artyom Beilis via Boost a écrit :
From my experience JSON-RPC is rarely/ever used. It was one of the early things I implemented back in the days for CppCMS.
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.
I'll actually think of quite the opposite. I could be interested in a transport agnostic json rpc interface. Let me deal with the transport, what i wish from a server json rpc library is : * it does the parsing of json rpc, incrementally * it allows me to register method handlers, which are called when the corresponding method is received * separation between the configuration and the parser (one single shared configuration, and multiple (1 per client) server channels which uses the same configuration) * it produce replies (ie, is able to json-serialize, potentially via describe) from the return value of the called handlers or whatever mechanism it wishes, either synchronously or asynchronously, as buffers of chars
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 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).
To me it looks a lot more like a reason for not doing it in the library. Provide a jsonrpc facility, that can run over any text stream (including a basic text file, actually just consume a bunch of chars), and let the user choose whatever is the best fit for the transport. This also makes the whole stuff a lot easier to test. In that vision, asio is not relevant anymore. But an asio raw tcp implementation can be built on top of that, like would an implementation on top of beast, or http2, or whatever. It makes a lot of sense to provide them, but it also makes a lot of sense to not require them to use the library.
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.
Custom serialization may be relevant for some users, but custom transport is more relevant for my use case. Regards, Julien