[DAS] RFC: REST example for DAS 2.0

[Andrew Dalke]

[Blech!  I'm subscribed to this list as "dalke@dalkescientific.com" since
that is my primary email address.  But my 'From' is "adalke@mindspring.com"
because my ISP won't allow me to do otherwise.  So every message I send
gets held for moderation.  Sorry about that moderators.]

Lincoln Stein:
> As long as there are good Perl/Java/Python 
> APIs to DAS and performance is usable, none of the target audience 
> (applications developers) are going to care in the least whether it's
> SOAP or not. 

I agree.

> My concern with SOAP encapsulation is that it makes it harder to
> stream DAS, at least with my favorite language, Perl.  But I've got my
> fingers crossed that eventually there will be a good streaming SOAP
> for Perl, and at that point all my misgivings go away.

Given my readings, I do not think this will happen
http://www.xml.com/pub/a/2002/07/17/salz.html?page=last
} Note that even though the individual processing is fairly simple,
} the overall process is fairly complex and requires multiple passes
} over the header elements. In a streaming environment -- think SAX,
} not DOM -- that won't work. In fact, it's my bet that headers will
} spell the end of SAX-style SOAP processors. For example, a digital
} signature of a SOAP message naturally belongs in the header. In
} order to generate the signature, you need to generate a hash of the
} message content. How can you do that without buffering?

Brian mentioned DIME, which may.  I do not think that DIME solution
affects my comments on caching and on fetching only new features. 
 
> My understanding of REST is that it's defined by the negative -- it
> isn't SOAP.  That's not going to provide much in the way of
> reusability.

I would rather say that most times SOAP isn't REST.  The papers
I've read offer plenty of example of what a REST-style architecture
is (as compared to the negatice.)

Quoting from  http://www.xfront.com/REST-Web-Services.html 
    *  Client-Server: a pull-based interaction style: consuming
components pull representations.
    * Stateless: each request from client to server must contain all the
information necessary to understand the request, and cannot take
advantage of any stored context on the server.
    * Cache: to improve network efficiency responses must be capable of
being labeled as cacheable or non-cacheable.
    * Uniform interface: all resources are accessed with a generic
interface (e.g., HTTP GET, POST, PUT, DELETE).
    * Named resources - the system is comprised of resources which are
named using a URL.
    * Interconnected resource representations - the representations of
the resources are interconnected using URLs, thereby enabling a client
to progress from one state to another.
    * Layered components - intermediaries, such as proxy servers, cache
servers, gateways, etc, can be inserted between clients and resources to
support performance, security, etc.

Here's the PhD dissertation describing REST
 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
in full glory.


				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/