Chronological Thread 

< Chronological >      < Thread >

---

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