Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011
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? Cheers, Alan. -Original Message- From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- boun...@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@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011
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:stringWorkspaces/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-boun...@cellml.org [mailto:cellml-discussion-
boun...@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
Re: [cellml-discussion] ABI CellML Meeting Minutes, 22nd June 2011
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?
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:stringWorkspaces/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.
Thanks a lot, Tommy. I am clearly not a web service expert and therefore
assumed that the choice was between SOAP, REST and JSON. From what I now
understand (which may still not be right!), it would seem that the choice is
between SOAP and REST while regarding JSON it
