my 2 cents

By writing this post, I noticed that it’s quite some stuff, so I broke it up in parts. This part is about the new specifications which help to standardize JSON protocols/apis.

When we started to implement Tine 2.0 about 2 years ago, we got quite some confused request why we chose JSON over SOAP as our data transport between the server and the client. Technically the answer is very easy. JSON protocols only need a fraction of the bandwidths and even more important JSON has a significant better performance on client side, cause no XML parsing is needed.

On the other hand, two years ago SOAP was a mature protocol but JSON only an data encapsulation and no real standards did exist, so that we where forced to implement a custom protocol.

Fortunately this has changed in the last two years. There are three cool standardization efforts in the JSON community I’d like to introduce.

1. JSON-RPC: It’s a lightweight remote procedure call (RPC) protocol. The clients request consist only of a single JSON data telegram and does not use HTTP parameters:
   

   --> {
       "jsonrpc":"2.0",
       "method":"Tinebase.login",
       "params": {
           "username":"tine20admin",
           "password":"lars"
       },
       "id":2
   }

   
   

   <-- {
   "id":"2",
   "jsonrpc":"2.0",
   "result":{
       "success":true,
       "account": {
           "accountId":"0e7d07cb453b15f520021e0a433956b234a7c0bd",
           "accountDisplayName":"Admin Account, Tine 2.0",
           "accountLastName":"Admin Account",
           "accountFirstName":"Tine 2.0",
           "accountFullName":"Tine 2.0 Admin Account",
           "contact_id":"1"
       },
       "jsonKey":"85160b59b4421bbe2f350c5b3888a2efdbfcb949",
       "welcomeMessage":"Welcome to Tine 2.0!"
   }}

   Multi batch calls are also possible. The client only has to send an array of request objects. Unfortunately the Protocol does not handle “Form-Posts” which are necessary for some special actions like file-uploads.

   But nevertheless libraries are starting to implement the spec and this is the most important thing about it!

2. JSON SMD: It’s a JSON representation for describing a web service. The server ‘exposes’ it’s services to the client.
   

   {
   "transport":"POST",
   "envelope":"JSON-RPC-2.0",
   "contentType":"application/json",
   "SMDVersion":"2.0",
   "target":"index.php",
   "services": {
       "Tinebase.login":{
           "envelope":"JSON-RPC-2.0",
           "transport":"POST",
           "parameters":[{
               "type":"string",
               "name":"username",
               "optional":false
           }, {
               "type":"string",
               "name":"password",
               "optional":false}
           ],
   "returns":"array"}}}

   The client can use this descriptions to automatically create the stubs for calling the services which already encapsulates all the proxy and transport and protocol overhead. With this, instead of creating an AJAX request per hand you only have to call the method:

   Tinebase.login('tine20admin', 'lars', cb);

   where cb is a callback function, cause we do our requests asynchronous.

3. JSON Schema: Quoting their website: “JSON Schema is a specification for a JSON-based format for defining the structure of JSON data.”
   Of course the idea is pretty old in the world of web-services, but it’s the first approach to bring this to the new area of javascript based RIA’s which use JSON for the reasons stated above.With this we not only expose the services to the client, but more over also the data types. The benefit is clearly that we don’t need to maintain the data models client side and also the client side data validation could be made client side automatically.

In Part 2 I’ll introduce Ext.Direct and go into the details how to apply this new standards within the Ext.Direct framework.