use JSON::RPC::Common::Marshal::HTTP; my $m = JSON::RPC::Common::Marshal::HTTP->new; my $call = $m->request_to_call($http_request); my $res = $call->call($object); my $http_response = $m->result_to_response($res);
When encoding a call into a request, prefer GET.
When encoding a GET request, use REST style URI formatting (the method is part of the path, not a parameter).
When set and a
params param exists, decode it as Base 64 encoded JSON and use that as the parameters instead of the query parameters.
Defaults to the marshal object's class name and the JSON::RPC::Common version number.
When explicitly set these are the values of the
Accept headers to set.
Otherwise they will default to
application/json with calls/returns version 1.0 and 1.1, and
application/json-rpc with 2.0 objects.
Whether or not to use an expander on
GET style calls.
An instance of CGI::Expand or a look alike to use for
GET parameter expansion.
Get requests call
Parse a call from a GET request's URI.
Write the result into an object like Catalyst::Response.
A variant is chosen based on
The error handler will ensure that "error" in JSON::RPC::Common::Procedure::Return is set.
Convert a call to a request (or just a URI for GET requests).
The arguments can contain a
uri parameter, which is the base of the request.
With GET requests, under
rest_style_methods that URI's path will be appended, and otherwise parameters will just be added.
POST requests do not cloen and alter the URI.
If no URI is provided as an argument,
/ will be used.
encoded can also be passed to
call_to_request to alter the type of request to be generated.
Only used for query encoded GET requests. If
expand is set will cause expansion of the params. Otherwise it's a noop.
Subclass and override to process query params into RPC params as necessary.
Note that this is NOT in any of the JSON-RPC specs.