JSON-WSP or JSON-RPC [closed]

Question

We're about to implement a webservice using JSON objects as the mode of transportation. We have an intent of having third-party organizations to connect to our network and for that we are planning to use a standarized protocol to ease integration in the future.

For JSON, there's two specifications at the moment: JSON-RPC and JSON-WSP. I would like to know about anyone's view between these two and what would you use if you're in my shoes. For now, I see that JSON-RPC has been around for a while and has implementations to multiple languages. JSON-WSP is at its early stages but it aims to supersede JSON-RPC (an RFC is in the works). I see that JSON-WSP will be a good solution in the long run but I might be wrong.

Answer 1

The main difference between the two protocols is that JSON-WSP can describe it's own service methods with the jsonwsp/description object. This is nice if you want your client to be able to "know" your webservices and maybe offer a dynamic client-side user-interface that can change visualisation automatically when you change the service methods. So server-side updates can potentially become very easy to distribute.

JSON-WSP has support for attachments in the specification

JSON-RPC has support for batch-method invocation - invoke several method in one request. Also you can do response-less requests (Notifications)

JSON-RPC is the oldest of the two protocols and therefore it has more implementations and a large community.

So I guess it all boils down to what your needs are.

If you are building a browser-based application JSON-WSP offers an efficient Ajax-based mechanism using the official javascript client. The JavaScript json-wsp client parses the service description and generates a proxy object with methods mapping 1-to-1 to the json-wsp methods:

http://ladonize.org/index.php/Python_Example#JavaScript_JSON-WSP_client

Answer 2

Why not use REST?

If you already know the format of your JSON types, document those as the representations of your individual resources and then offer access to them via HTTP. That way, you'll get the benefit of the underlying transport infrastructure (caching possibilities, great tooling, etc).

Use hyperlinks between each resource to allow the clients to navigate between them. The users of your API then won't be tied to a contract-based RPC mechanism which will be hard for you to evolve and requires yet another toolkit for your clients to use. Using REST will require only an HTTP library (they are a dime a dozen) and a JSON parser (which they already need). In addition, you could always later add other encoding options (say, XML) with minimal impact to your existing clients.

Using JSON does not mean having to choose between JSON-RPC or JSON-WSP. Go for the lowest common denominators for your API with long-established, uber-simple standards (like HTTP and JSON) and use them to their best advantage. Once you start layering more specs and standards in there, you'll find that the complexity of your API grows proportionally.