W*S and REST, Again

I'm experimenting with watching Planet Geospatial less, and stalking more keywords on Technorati. This led me to a blog I hadn't seen before, and a post asserting the RESTful-ness of OGC W*S, a notion that I thought we'd put to bed last year.

Statelessness, HTTP transport, and use of URLs are necessary but insufficient elements of RESTful architecture. Statelessness is only one aspect of "hypermedia as engine of application state". Using HTTP as a simple pipe, ignoring request and response headers, is not RESTful. Finally, the important thing about URLs is that they can be dereferenced to obtain a resource. This WFS query:

http://example.com/cgi-bin/wfs?
  typename=PointsOfInterest&
  maxfeatures=50&
  SERVICE=WFS&
  VERSION=1.0.0&
  REQUEST=GetFeature&
  SRS=EPSG%3A4326&
  BBOX=3.048788%2C36.755769%2C3.071012%2C36.773231

is not a resource URL. It's a remote procedure call.

Comments

Re: W*S and REST, Again

Author: Allan

OK, I'll bite. To what extent would a collection of GML objects returned by a query be a resource no matter how you request it? Or, put differently, how would you do the same thing in REST? I guess in database terms, you could define a View as a query and then the resource would be the view. Or the view would be the resource. In that case, then it would see to me that http://example.com/cgi-bin/wfs?view=[query expression] would point you at a resource. Then if you substitute the actual WFS request for [query expression] you have REST. So REST depends on the plausibility of calling the thing you get back a resource. I think early on Ron Lake was pushing XQuery, Xpath, and XLink as the means of doing what a WFS does. Would that me more RESTful? I'm neither a full-bore student of REST, nor a database person, so the distictions may be too subtle for me.

Re: W*S and REST, Again

Author: Paul Ramsey

It is not clear to me that the W*S baseline as currently defined can be mapped neatly into REST. The example that has the most resonance for me is WMS versus Google Maps. Both provide a way of getting maps on your screen. By pivoting the problem slightly, Google Maps is able to provide a completely RESTful solution to the problem (every tile is definitively a resource). Now, I could flip WFS into REST easily enough, by defining each feature as a resource. But I am not sure how scalable that approach would be. At some point you need to query. And frankly, that aspect of RESTful handwaving still eludes me: how is a REST query operation any less of a schmozzle than any other web services query? And once your data domain gets large enough that the only practical way to work with it is via query mechanisms, is it still possible to see the RESTful aspects of the design behind all the querying? At that point does REST not degerate into the much simpler "I push XML over HTTP, and try to respect the HTTP operations and headers while doing so".

Re: W*S and REST, Again

Author: Sean

You misunderstand me. Queries are essential to a RESTful GIS. I'm only reminding readers that WxS is RPC, not REST.

Re: W*S and REST, Again

Author: John Caron

We are trying to define a RESTful alternative to W*S. I would really appreciate understanding why "WxS is RPC, not REST" and how to do the same thing RESTfully. My best guess would be something like http://example.com/cgi-bin/wfs/PointsOfInterest/EPSG%3A4326? BBOX=3.048788%2C36.755769%2C3.071012%2C36.773231& maxfeatures=50 The role of query parameters vs. URI path is rather confusing.