Qubit without JSON-RPC?

[akx]

For client implementation simplicity, I'd like to use Qubit without having to use JSON-RPC. In other words:

• #[handler(query)] fn hello_world() would map to GET /rpc/hello_world with query-string parameters, if any
• #[handler(mutation)] fn hello_world() would map to POST /rpc/hello_world with a JSON body

... and, well, that's it I guess? A generated browser client could just use native fetch().

I suppose this wouldn't be too difficult to implement, but I wouldn't want to fork qubit, or work on something that would not be accepted to core.

[andogq]

I certainly don't have anything against the idea! I originally decided on the single endpoint for the following reasons:

• aligned with TRPC's endpoint structure
• easier integration for deployment, as wildcard endpoints may not always be possible
• JSONRPC uses a single endpoint

I'm interested to know the use case for an alternate structure, is there something that the current setup prevents you from doing?

My other hesitation is it would require significant updates to the client. For instance, it's currently transport agnostic (GET/POST/web socket/???), which would be a lost feature with this new setup.

[akx]

Right, so my use case would really be "simple, type-safe-for-TypeScript, plain old HTTP(S) RPC-style API".

Not having a single endpoint (where the payload determines what actually happens) is easier to audit with traditional tools (you can just grep a log file to see what calls are being made), and easier to trivially debug with e.g. curl.
(I spent a small while wondering why I couldn't get any output from curl -vv http://localhost:3000/rpc --json '{"jsonrpc":"2.0","method":"get_version","params":[]}' – well, yeah, a JSON-RPC call without an id is specified to be a notification sans return value.)

But again, this'd be an alternative – something like router.to_simple_service() (or whatever, naming is up in the air of course) – to the current JSON-RPC-talking service (ditto for client generation).