Handle parameters by name
dcharbonnier opened this issue · 10 comments
http://www.jsonrpc.org/specification#parameter_structures
If present, parameters for the rpc call MUST be provided as a Structured value. Either by-position through an Array or by-name through an Object
Yeah, I always thought about updating that, since it can only handle arrays at the present moment (and are used JSON-RPC 1.0 style everywhere), but the change shouldn't take much time since, it needs to check the type of parameters in handleCall, and pick either apply or call depending on the type
EDIT: actually the code is quite tied to the current "array as parameter" convention, more than I thought.
Yes, I see no problem with the array-as-parameter.
Two problems left, named-parameters and batch (next issue;-). I would like to allow either array and named for the same function.
My idea is to change the expose function to send parameters as named to the function on both case (already done a part of the job). But this should break the compatibility with previews version unless "hacking" to support current way of exposing methods. The good think is that we should be able to create automatically a documentation for the exposed methods with this solution and I really like the idea of self documentation for an rpc server.
I will publish a branch it will be easier to understand.
I like the idea, although the self documentation should be configurable. most of the time I use RPC internally, and expose a few public methods but that shouldn't be called by third-party people, but from my own external servers.
have a look at https://github.com/dcharbonnier/jsonrpc2-tools
example :
server.expose('categories', {
'find' : rpc.utils.setup(server.dummy, {
middlewares: [rpc.middlewares.session, rpc.middlewares.auth],
args : [
{'name': 'limit', 'type': rpc.types.UnsignedInt},
{'name': 'start', 'type': rpc.types.UnsignedInt},
{'name': 'sort', 'type': rpc.types.String, 'enum': ['popular', '-popular'], 'default': '-popular'}
],
desc : 'Get categories',
response : '[type.Video]',
example : '\
\nvar wupapi = new $.JsonRpcClient({ ajaxUrl: \'/backend/jsonrpc\' });\
\nwupapi.batch(\
\n function(batch) {\
\n batch.call(\'categories.get\', [\'d39db8ba-24ff-4bdc-957b-0df6e91b3f36\', 10 ], success_cb1, error_cb1);\
\n },\
\n function(all_result_array) { },\
\n function(error_data) { }\
\n);',
mode : rpc.mode.READ
}),that's some fancy stuff you got there :D
but where the actual method is declared?
The example is a full declaration. It's still compatible with current expose method nothing is required.
The method is server.dummy. I just wrap the method with the setup.
It give me automatic documentation (will do a screen shoot) named arguments + positional, and arguments check.
It raise error if argument is invalid.
The middlewares are also nice. I have for example a session middleware, an authorization middleware in my current app.
Implementation is not perfect but 100% test coverage.
very nice, would never thought about making this RPC module so featureful, but I had in mind that I had to make it easily extensible (through the ES5Class module)
awesome stuff @dcharbonnier looks really good