RESTful Web services and DAL
Matthew Graham
mjg at cacr.caltech.edu
Tue Mar 13 12:07:24 PDT 2007
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
More information about the grid
mailing list