[DAS] RFC: REST example for DAS 2.0

[Andrew Dalke]

Brian Gilman:
> I've also thought about REST as a means to
> make a distributed system. But, the industry is just not going that way.

Says the Java guy talking to Perl and Python coders.  :)

The direction of industry should be an influence, but not a deciding
factor.  ("If everyone else were to jump off the Empire State
building....")   In my posts I said that so far SOAP has been tricky
to use (interoperating between Python, Perl, and Java),  and the benefits
of SOAP given in the RFCs are not unique to a SOAP approach.  I also
said, as you verified, that SOAP isn't useful for streaming over
large responses, and pointed out an alternate way to approach it that
the current 1.5 spec nor RFC 13 support.  I also pointed out that a
SOAP approach makes it hard to do caching.

[Actually, itemized list of reasons at the bottom of this post.]

> There are MANY toolkits to program up a web service.

Yes, and I tried 4 of them for Python and the SOAP::Lite one for
Perl.  I also mentioned there are many toolkits to program up a
REST service, since they already exist for standard web programming.

> Programming a REST
> service means doing things that are non-standard and my engineering brain
> says not to touch those things.

How is it non-standard?  A search can still be a SOAP request (or
XML-RPC which is just as useful as SOAP and much less complicated).
Returning XML w/ a DTD is standardized, and the DTD can be used to
generate a native data structure.  True, the DTD doesn't handle type
schemas, but that can be verified with an external schema.  (Based
on the work of people I know, I'm now leaning towards RELAX-NG, but
that's a different topic.)

> SOAP has been able to solve a lot of
> interoperability problems and will only get better over time. We use the
> DIME protocol and compression to shove data over the wire. No need to parse
> the document this way.

And XML-RPC has been able to solve a lot of interoperability problems
and is mature and stable.  What advantages does SOAP bring?

DIME?  Here's what I know about it (dated 2002/09/18)
  http://www.xml.com/pub/a/2002/09/18/ends.html

According to that, DIME is more of a de facto standard than a de jure
one, so how does that affect your engineering brain?  ;)

More seriously, it's layers upon layers.  As I read it, the DIME message
holds the SOAP message, and is decoded to get the SOAP portion out.
(This is because DIME is a binary format and may contain XML metacharacters.)

Therefore, why not return the DIME message without the SOAP part?
Just include the data sets directly.

>     SOAP has two methods of asking for data:
>         
>     1) RPC
>     2) Document centric
> 
>     My question to you is: Why reinvent the wheel?? Why program up yet
> another wire protocol when you have something to work with already??

RFC 13, which suggests WSDL and UDDI for a DAS 2, is RPC not
document centric.  I agree that everything I mentioned for my
REST example can be done over SOAP, in which case SOAP is
being done for pure serialization.  However, even in that case
you limit caching (RFC 5) because SOAP requests are all done via
POST and the cache doesn't know if a POST request has side
effects or not.  

How am I reinventing the wheel?  In my example recasting of DAS I
created no new wire protocols.  Everything was returned in XML with
a DTD.  Just like in RFC 13 there's a new WSDL for every query.
So there are equal numbers of new definitions required.

> And, DAS, is a REST protocol!! Right now DAS just works.

I disagree.  Two data types, features and types, are not directly
addressable.  They are only retrievable as part of a search, ie,
the 'types' and 'features' commands.  (Semantically
'features?feature_id=ABC' returns a list of matches, either of
length 1 or 0, as compared to a name which returns the object or
says "404 Not Found")

This means that DAS as it stands doesn't allow "InterService links"
as requested for RFC 3 nor allows RDF-style commentary and metadata.

And so I believe DAS 1.5 is not a REST protocol.

> Why change it to use
> anything else?? Is there a problem with the semantics of the protocol that
> impede any of the research that we are doing?? Murphy's law should be called
> the engineer's prayer.

Yes, as listed:
  - improved performance because previously fetched features do not
      need to be re-retrieved for every search
  - better integration with existing http caching proxies
  - protocols are easier to understand
  - toolkits for doing this are more widely available (than SOAP,
      they are the same toolkits for the existing DAS spec)
  - able to make links to a feature, eg, with RDF (which can also
      address RFC 10 on "normalizing groups")
  - easy support for streaming
  - easy extension to DAV for making a *writable* system using
     standard and widely available authoring tools

Do they "impede research"?  The performance ones make it easier
to work with distant data sources and easier to develop more
interactive tools.  The ability to make direct links is, I
believe, a big but untapped advantage.  The support for writing
makes it easier for people to maintain a DAS system.

				Andrew Dalke
				dalke@dalkescientific.com
-- 
Need usable, robust software for bioinformatics or chemical
informatics?  Want to integrate your different tools so you can
do more science in less time?  Contact us!
               http://www.dalkescientific.com/