bitboxer / jimson

JSON-RPC 2.0 client and server for Ruby

Jimson

JSON-RPC 2.0 Client and Server for Ruby

Client: Quick Start

require 'jimson'
client = Jimson::Client.new("http://www.example.com:8999") # the URL for the JSON-RPC 2.0 server to connect to
result = client.sum(1,2) # call the 'sum' method on the RPC server and save the result '3'

Server: Quick Start

require 'jimson'

class MyHandler
  extend Jimson::Handler

  def sum(a,b)
    a + b
  end
end

server = Jimson::Server.new(MyHandler.new)
server.start # serve with webrick on http://0.0.0.0:8999/

JSON Engine

Jimson uses multi_json, so you can load the JSON library of your choice in your application and Jimson will use it automatically.

For example, require the 'json' gem in your application:

require 'json'

Previous maintainer

This gem was maintained by Chris Kite till April 2021.

jimson's Issues

Jimson currently can't be used in rails 5 because of conflicting Rack versions

Hi,

At present, Jimson depends on:

"rack", "~> 1", ">= 1.4.5"

and is thus unusable in a rails 5 app because ActionPack 5.0.0rc1 depends on:

'rack', '~> 2.x'

Marshalling complex objects?

Thanks for this great library! Is it possible to get more complex objects across the wire instead of primitives?

Return only jimson exceptions

Jimson should send back only errors from Jimson::Server::Error or inherited ones. Now it can send errors like NoMethodError.

If you like it, I'll contribute this feature.

Show the response that was received for invalid response

It would be nice for debugging purposes if you would show the response received for Client::InvalidResponse just as you do for InvalidJson

support for multi_json 1.7.x

Would it be possible to rev the multi_json dependency to ~> 1.7.0 from 1.1.0?

Does not support using named parameters

client.method({'bar' => 'baz'}) will set params to [{'bar' => 'baz']] instead of {'bar' => 'baz'}

HTTP keepalive (feature request)

HTTP keepalive would be nice.

params passed as an array while a json object is expected

So, I've been playing with a Counterparty json-rpc server (for reference, don't look too hard at it: http://counterpartyd.readthedocs.org/en/latest/API.html) and it returned me an error everytime I tried to make a request with params saying the following:

{ "message": "Invalid Request", "data": "Arguments must be passed as a JSON object (list of unnamed arguments not supported)" }

I digged deeper into your code and found the issue here:

module Jimson
  class ClientHelper

    def send_single_request(method, args)
      namespaced_method = @namespace.nil? ? method : "#@namespace#{method}"
      post_data = MultiJson.encode({
        'jsonrpc' => JSON_RPC_VERSION,
        'method'  => namespaced_method,
        'params'  => args.try(:first), # <= PROBLEM WAS HERE: it was just `args`
        'id'      => self.class.make_id
      })
      resp = RestClient.post(@url, post_data, @opts)
      if resp.nil? || resp.body.nil? || resp.body.empty?
        raise Client::Error::InvalidResponse.new
      end

      return resp.body
    end

  end

end

So it seems the server I'm interacting with expects params to be a json object and not an array. The fix I applied - using the first element of the array - works, however I'm not sure whether this is something specific to the Counterparty RPC server or maybe it's jimson implementation deficiency. Please take a look at it, you might want to decide to give users more freedom as to how to pass params.

Methods with dots

Is there any way to call methods like "user.login"?

Cannot use with JSON-RPC 1.0 clients (e.g. Bitcoind)

Bitcoind does not send "jsonrpc" header back, so without patching jimson it's not possible to use the Jimson client.

[Feature] Support for namespace

I would like to discuss the possibility to built in jimson some kind of namespace support as a convenience on top of JSON-RPC. This proposal could be implemented in two ways:

Using methods

When the a request comes and the method is "foo.bar", we would invoke "foo" on the handler object that would return another object which "bar" would be called on. However, this approach could lead to security vulnerabilities (for example, given a function returns an array, one could call methods on the Array like pack/unpack that could be CPU or SPACE intensive).

Explicit exposure

A better approach is to whitelist which methods allow nesting, this could be in the Handler API. A proposal is the jimson_nesting method:

extend Jimson::Handler
jimson_namespace :service1

My case

My case is that I want to expose several services via JSON-RPC without actually having to create many ports. For example:

module Handle
  extend Jimson::Handler
  def service1; Service1; end
  def service2; Service2; end
end

And then I would like to invoke it as: "service1.foo".

Client

Today, the client uses method missing and this approach doesn't work with namespace. One option is to allow namespace in the client:

service1 = client.namespace(:service1)
service1.foo

This would be a very thin wrapper around the client that would basically convert the method to "service1.foo".

What do you think? In case you are interested in something like this, please let me know and I will gladly implement it. :)

[Improvement] Support for modules as handlers

Today, I cannot use a module as a handler:

module MyModule
  extend Jimson::Handler
  def sum(a, b)
    a + b
  end
end

server = Jimson::Server.new(MyHandler)

The reason this fails is because the server expects the class of the object given to respond to a jimson method:

https://github.com/chriskite/jimson/blob/next/lib/jimson/server.rb#L168

A possible approach to this problem is to move this method to the instance, probably something along the lines of jimson_respond_to?. We could use the extended hook to inject this method in the instance.

If agreed, I can work on a pull request. :)

Compatible with Ruby 2.5

Hi,

jimson depends on rest-client ~> 1 and the latest from this lineage is 1.8.0.
rest-client 1.8.0 is not compatible with ruby 2.5 because of upgraded openssl interface.
"key not found: :ciphers"
rest-client-1.8.0/lib/restclient/request.rb:163:in `fetch'

I don't think that rest-client 1.8.1 will be released, so, do you have any plans to move to newer rest-client , say ~> 2 ?

Thanks.