Re: [wcsplus] Design of asynchronous request in DEWS WCS

Hi Ethan,

I agree with all your comments, thanks.  Regarding REST, I think the
main problem is with the XML POST method of reading data.  In REST, a
POST means a "create", not a "read".  A RESTful service would only use
GET for reading data, but OWS requests can sometimes be long and
complex and hard to fit into a URL using KVP.  REST takes a
resource-centric approach, but to my mind OGC services are
query-centric.  I think it's going to be hard to make a truly RESTful
OGC service but I haven't done much thinking about it.

My main worry is that I've met a lot of people who seem to think that
"REST" simply means "not SOAP" and so they think that OGC services are
already RESTful, or that it would be easy to change to a RESTful
design.  Therefore I was keen to ensure we were all on the same page
on this list! ;-)

Cheers,
Jon

On 11/1/07, Ethan Davis <edavis@xxxxxxxxxxxxxxxx> wrote:
Hi Jon,

Jon Blower wrote:
I think negotiation could potentially be important, but I'm not sure
this is a feature for a first cut, especially if we're doing this in
limited time (Ben D. has already said in a different email that there
are concerns about whether async operation can be implemented in
time).  The main practical issue here is that it's very difficult for
a server to give an accurate estimate of how long a job will take.  It
would certainly be possible to create such a mechanism but I think
this would need a *lot* of experimentation and thought.  It's a
perfectly valid requirement but I would prefer to see some evidence
that this is really needed because I think it's going to be hard.


I agree. Let's implement and see how it goes before working on these
details.

Regarding my concerns about HTTP response codes and REST to marshal
the conversation on asynchronous behaviour.  Again, I think this is a
perfectly valid approach and my concerns aren't too critical, but my
nagging doubts are:

1) In my experience, http response codes are often not used well by
servers and clients.  It's fine to include them in a spec, but I would
prefer to ensure that the information they carry is duplicated in any
XML response, so clients don't have to infer too much from the
response code.  (E.g. it's fine to specify that a server should
respond with 202 ACCEPTED, but there should also be an XML document
giving more information.  Maybe that's what you were saying anyway.)


I agree that they are often (even mostly) not well used. I also agree
that the response code information should be duplicated (and expanded
on) in the response content.

On the other hand, I don't think a robust system (perhaps especially a
distributed system) can be developed without a fair amount of thought
put into error and exception handling. The response codes are a very
small and quick check (as opposed to parsing an XML document). Also,
handling them well makes server logs much more informative.

2) Do we need redirects at all?  I'm not sure that we do, if we follow
the WPS method of embedding URLs to data objects in the XML response.


Again, this is about building a robust system that can evolve
gracefully. Server software will change, URLs will change, it makes it
much easier to maintain an HTTP client/server system if clients supports
redirects. Redirects are also often used to switch from HTTP to HTTPS
for authorization/authentication.

3) My concern over REST is that none of the OGC specs (to my
knowledge) follow REST principles and I think it's more important to
follow the OGC conventions than apply a new paradigm.  In the real
world you can only rely on clients knowing how to do a GET and POST
(PUT and DELETE are poorly supported, e.g. in Ajax-style operations.
But perhaps you weren't considering using PUT or DELETE anyway).  One
of the very nice things about the existing OGC specs is that I can get
data, images etc directly through a web browser and it helps the
community to develop nifty web applications (like OpenLayers).


There was a lot of REST discussion at the Boulder TC meeting so it will
be interesting to see how things develop wrt REST at OGC.

For WCS, I'm not thinking about PUT or DELETE.

I agree, the ability to access data from a browser is very handy. And, I
think, very important to wide spread adoption of WCS and other OGC
specs/services. I think REST will help in this respect much more than
the current push for SOAP and even XML POST.

Hope this helps.  I agree completely that the top priority is a clear
spec, but we do have to make sure that it's easy to implement
properly.  I guess that's the point of interop experiments!


Agree. And, along with the balance between simple and clear, we need to
find balance between simple and robust.

Thanks,

Ethan

--
--------------------------------------------------------------
Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
Technical Director         Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre   Fax: +44 118 378 6413
ESSC                       Email: jdb@xxxxxxxxxxxxxxxxxxxx
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------