jsonrpc-client
jsonrpc-client copied to clipboard
fxposter
Support for named parameters
We should have support for named parameters when making JSON RPC calls, this patch makes it possible to do just that with minimal modifications.
When the user asks for client.foo(1) or client.bar(1,2) we should make an array, so the resulting params key should have [1] or [1,2] respectively.
When the user asks for client.foo(:bar => 'foo') we should pass them directly, so the resulting params key should be {"bar": "foo"}.
I don't like the solution. If the first argument is JSON object - you will not be able to pass it at all.
client.foo(:some => { :nested => :hash }) - this is the call of method foo with the first parameter { :some => { :nested => :hash } }
No, I mean that my hash is not named params, but just the first parameter of the method. In your implementation we cannot do this anymore.
Agrh! You are right, of course, but that don't leaves us with a lot of choices.
What I was thinking about is will it be better to make the user decide in which mode the parameters are sent to the endpoint. I mean something like this: JSONRPC::Client.new('http://example.com', :named_params => true) and that way for that particular endpoint we know to communicate with named params and not positional. Will leave the option false by default for compatibility.
Can we do that?
Hey, I was wondering did you had time to see the latest refactoring and will you merge them? And if not how can I change it to make it better?
Hi, I've got an API I'm attempting to use jsonrpc-client for and it requires named parameters and will explicitly reject requests that are nested inside an array. Will there be any further progress on this PR?
It's trivial to build an RPC client using faraday and a simple middleware: https://gist.github.com/romanbsd/f3af3addc88405a55a9c4c577b5525dc
@romanbsd Thank's for the suggestion, that looks perfect for my needs as a very basic client.