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

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 would, if anything, be a
choice between XML and JSON. So, in the end, it would seem that it might be
a choice between say SOAP+XML and REST+JSON. If that is the case, then
REST+JSON seems like a better choice for PMR2 indeed. Please feel free to
correct me if I am still missing something...

Alan

_______________________________________________
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Reply via email to