Alan Garny wrote:

Having just read the minutes, I was wondering whether you guys could clarify
the situation with regards to web service support for PMR2? Tommy said that
"REST support is iffy" and that's also what I understood from the email he
sent around earlier this week. However, the minutes read that the "general
upshot is that REST is likely to be the technology of choice"...?! I can't
see the rationale here. So, would it be possible to have some explanations?
Also, in Tommy's email, he mentioned JSON (in addition to SOAP and REST).
So, what about JSON?

Hi Alan,

REST support is iffy is in relation to standards/libraries that provide/support 
within the standard Zope/Plone environment.  What this means is I will have to 
implement anything that isn't there natively.  However, REST really is a 
methodology for transferring of states, and in PMR2's case there isn't really 
that much to add.

As for how these states are transfered, there are many ways to do so, either 
via XML, JSON or other formats.  Since JSON is the preferred encoding method 
for values this is why we tentatively decide to do so.  JSON and REST are two 
complete independent entities and are completely different types of concepts 
that gets used together a lot.

SOAP on the other hand is a design-by-committee standard that ends up being 
excessively verbose for what we are trying to do, which is to provide a 
lightweight method to retrieve values from PMR2.  I did start off doing this in 
SOAP with a library that the Zope community provided.  It was easy to get going 
because SOAP is an established standard, but under the hood it was anything but 
simple.  This is the request body to get the title of an object generated by 
the SOAPpy library:

<?xml version="1.0" encoding="UTF-8"?>

<get_title SOAP-ENC:root="1">

This is the response by the Zope SOAP library I added:

xmlns:SOAP-ENC=""; xmlns:SOAP-ENV="";
       SOAP-ENC:arrayType="xsd:anyType[1]" xsi:type="SOAP-ENC:Array">
     <element id="ob2d7f20" xsi:type="xsd:string">Workspaces</element>

Whereas with JSON it's more of a simple standard HTTP GET to a specific URL 
(which we will have to define) and response body would look something like

 "title": "Workspace"

An order of magnitude of reduction in bytes.

A response for a list of workspace with its URL looks something like this per 

"Per Pixel Lighting": "http://localhost:8380/pmr/workspace/per_pixel_lighting";,

Rather than this

<SOAP-ENV:Envelope ...>
 <Eoced4c60 id="oced4c60" xsi:type="xsd:string">
   Per Pixel Lighting
 <Eocedc260 id="ocedc260" xsi:type="xsd:string">

For JSON, all you need is to use a standard JSON library, load the string, and 
you have the values you need.  Ditto for SOAP, but the transport body is just 
excessively verbose - added bytes for no added benefits in our case.

To submit changes in the REST protocol I plan to implement for PMR2, you should 
be able to construct a standard POST request to one of our standard forms and 
things will be done.  While some people would argue we should allow users to 
PUT stuff, we don't actually support that with our current web front-end anyway 
because PMR2 generates the content (i.e. exposures and their associated 
pages/views) based on commands user sends via standard http POST forms.

If you want to know more as to why REST is displacing SOAP, search 'REST vs. 
SOAP' in your favorite search engine - evidence for why is too numerous to list 

Okay, I will try anyway:

Popularity between REST and SOAP

Google deprecated SOAP API two years ago (their encoding is in atom and json):

BioModels are moving to a REST API, not sure what their encoding will be but I 
heard it will be json.

So yeah, these are the justifications.


Cheers, Alan.

-----Original Message-----
From: [mailto:cellml-discussion-] On Behalf Of Tommy Yu
Sent: 24 June 2011 06:49
To: CellML Discussion Group
Subject: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011


The minutes of the Auckland Bioengineering Institute CellML meeting of
June 2011 can now be found at:

Kind Regards,
cellml-discussion mailing list

cellml-discussion mailing list

cellml-discussion mailing list

Reply via email to