|
|
Boost : |
From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-04-11 15:28:36
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk