RESTful Web services and DAL

[Matthew Graham]

Hi,

Warning: this email contains views that some may take to be theological 
so if you want to remain secular and you are not interested in this 
supposedly "how many angels on a pinhead" discussion then please go and 
read the latest STC specification or something from the Data Models 
group instead,
> Having finally gotten through all this mail, here is my attempt to sort
> out the concepts.
>
> I suggest (based on e.g., the wikipedia and w3c descriptions) that a
> *Web service* is any service used by two computers to talk to each other
> via Web protocols.  Such a service will define an API which clients use
> to talk to the service.  (By this definition SIAP, WMS, etc. represent
> a type of Web service).  Individual Web services may or may not be
> stateful, but a comprehensive Web service mechanism needs to be able to
> support stateful services.
>   
I'm sorry but I think that you are redefining the term so that it fits 
things that would not commonly be termed web services. Wikipedia says: 
"in common usage the term [web service] refers to those services that 
use SOAP <http://en.wikipedia.org/wiki/SOAP>-formatted XML 
<http://en.wikipedia.org/wiki/XML> envelopes and have their interfaces 
<http://en.wikipedia.org/wiki/Interface_%28computer_science%29> 
described by WSDL 
<http://en.wikipedia.org/wiki/Web_Services_Description_Language>". The 
W3C definition is also explicit that "[a web service] has an interface 
described in a machine-processable format (specifically WSDL)."
SIAP may have an API but it is not described in any machine-processable 
format and this is the crucial difference. REST services do not really 
require a description language since their interface is described by the 
HTTP methods.
> A *SOAP Web service* is a web service which interfaces with clients
> via SOAP protocols running over the Web.  The main characteristic of
> SOAP is that it defines an XML-based mechanism for doing RPC calls.
> The main advantage of SOAP comes when one needs to bind a complex API,
> with multiple method calls, into multiple target languages; here the
> automatic binding made possible by SOAP and WSDL can be very useful.
> However, SOAP is complex and relatively inefficient, and there is more
> to distributed computing than low level synchronous RPC calls.  CORBA is
> similar, and also makes the mistake of over-emphasizing RPC.
>   
SOAP is a message framework for exchanging information and makes no 
assumptions how something is called. It has traditionally been used with 
WSDL to expose services in an RPC manner but practices are now changing 
towards a more document-oriented approach but still using SOAP (and 
WSDL). The automatic binding between WSDL and target languages is 
actually the source of most problems with web services.
> Wikipedia defines a *RESTful Web service* as a Web service which "attempts
> to emulate HTTP and similar protocols by constraining the interface to
> a set of well-known, standard operations (e.g., GET, PUT, DELETE)".
>
> The OpenGIS community introduces the concept of a "distributed computing
> platform (DCP)", used to implement the interface to a service.  HTTP,
> SOAP, CORBA, etc., are examples of such platforms.  For a well defined
> service, it should be possible, in principle at least, to execute the
> same service operations via any such DCP.
>
> A key characteristic of RESTful services appears to be an attempt to
> represent resources and state as "file" references, i.e., URLs in the case
> of the Web.  In Unix file system terms, /proc is an analogous mechanism.
>
> This would seem to work well for state, but a strict path-oriented
> approach (as in http://blabla.edu/cutout/301/22/bombayduck) does not
> work well for service operations.  Operations are hard to define with
> some sort of parameter or argument mechanism.
>
> Hence we see actual HTTP-based Web services using GET and POST to
> implement service operations.  REST suggests that GET should only be
> used for idempotent operations (the same operation can be performed
> multiple times with the same results, and does not visibly change the
> service state).  POST should be used otherwise.
>
> Although an idempotent GET with parameters, used to invoke a service
> operation which returns some result, may be mapped to many distinct URLs,
> it is still RESTful in many ways.  In particular it is consistent with
> the REST model of a fixed URL string which points to some "resource"
> and returns a file or document.  The parameter syntax departs from the
> simple file path seen in strict REST examples, but this does not appear
> to be an important distinction so long as a fixed URL returns consistent
> results.
Resource-oriented (RESTful) web services involve a different mindset 
from operation-oriented (RPC, SOAP) web services: it's like declarative 
vs. imperative (procedural) programming. It's not a case of just mapping 
a service call onto an HTTP URL but rather the resources and their 
representations have to be defined and then operations mapped to the 
HTTP methods. If you cannot come up with a clean resource-oriented view 
of your service then maybe a REST interface is not the answer and 
something operation-oriented is a better fit.
> An SSAP queryData operation to a single service for example, is just a
> GET which returns a document.  Within a given period of time, the same
> GET will return the same document; a number of such GETs may execute
> simultaneously on the same service, and each will return the same result.
> The same is true for an access reference, and in this case the URL is
> generated by the service and is a fixed string, hence the URL-based
> access reference is an even better example of a REST-compliant GET.
>   
Fine, this is a service and it can be exposed as a SOAP web service as 
well and but as soon as operations start taking centre stage, you're not 
talking REST anymore. It's just something that looks like REST because 
it uses URLs.
> What we need to look at next is how to handle stateful services.
> I haven't had time to look at Guy's example of this for the UWS pattern,
> but will do so when I get a chance.  In terms of the SIA concept of the
> stageData operation (which triggers the stateful/asynchronous part of the
> service), this would presumably mean a POST.  Queries for state could be
> done with GET using some session ID; it is not clear to me that this could
> not be done using a parameter syntax and still have a RESTful interface.
> What may not fit into the REST model well is asynchronous messaging.
> Perhaps this is just a GET where we hold the HTTP connection open and
> stream messages periodically?
>   
The REST way of handling stateful services is to treat the state of a 
transaction as a resource which is therefore addressable and manageable: 
note that this is just like the WSRF way of doing things. Submitting an 
asynchronous job (POSTing the details) will create a state resource for 
that job and representations of this resource (state queries) can be 
returned with GET calls to the resource URL.

I believe that keeping the HTTP connection breaks the idempotency of the 
GET call and so is not RESTful.

    Cheers,
   
    Matthew