Chronological Thread 

< Chronological >      < Thread >

---

Alan Garny wrote:
> Hi,
>
> 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"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
>
<SOAP-ENV:Body>
<get_title SOAP-ENC:root="1">
</get_title>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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

<SOAP-ENV:Envelope
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<get_titleResponse
SOAP-ENC:arrayType="xsd:anyType[1]" xsi:type="SOAP-ENC:Array">
<element id="ob2d7f20" xsi:type="xsd:string">Workspaces</element>
</get_titleResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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
entry:

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

Rather than this

<SOAP-ENV:Envelope ...>
...
<Eoceb8bec>
<Eoced4c60 id="oced4c60" xsi:type="xsd:string">
Per Pixel Lighting
</Eoced4c60>
<Eocedc260 id="ocedc260" xsi:type="xsd:string">
http://localhost:8380/pmr/workspace/per_pixel_lighting
</Eocedc260>
</Eoceb8bec>
...
</SOAP-ENV:Envelope>

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 here.

Okay, I will try anyway:

Popularity between REST and SOAP
http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/

Google deprecated SOAP API two years ago (their encoding is in atom and json):
http://googlecode.blogspot.com/2009/03/introducing-labs-for-google-code.html

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.

Regards,
Tommy.

> Cheers, Alan.
>
>> -----Original Message-----
>> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
>> bounces at cellml.org] 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
>>
>> Greetings,
>>
>> The minutes of the Auckland Bioengineering Institute CellML meeting of
> 22nd
>> June 2011 can now be found at:
>>
>> http://www.cellml.org/community/meeting/minutes/2011/06.22
>>
>> Kind Regards,
>> Tommy.
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://lists.cellml.org/mailman/listinfo/cellml-discussion
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion

---

• [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011, Tommy Yu, 06/24/2011
  • [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011, Alan Garny, 06/24/2011
    • [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011, Tommy Yu, 06/24/2011
      • [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011, Alan Garny, 06/24/2011
        • [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011, Tommy Yu, 06/24/2011

---

Archive powered by MHonArc 2.6.18.