The Need for Restful Services for Geospatial Information
So far the OGC has mainly interpreted Web Services in non-restful terms. While the idea of linking to remote resources has been part of GML since version 1., it has not been exploited in a restful sense in anything beyond the most simple experiments. As pointed out by Sean Gillies and others (see geo-web-rest@googlegroups.com ) rest depends on having a consistent http interface. Sean has already described this very well, so I will just quote his e-mail here:
“A uniform interface is the “core tenet” of REST:
(http://rest.blueoxen.net/cgi-bin/wiki.pl?RestInPlainEnglish)
For the Web, it is:
- GET: “give me a representation of the resource”;
- PUT: “replace the resource’s representation with this one”;
- POST: “create a new resource from this representation”;
- DELETE: “eliminate the resource”.
The closest thing WxS has to resources are the service endpoints specified by the online resource URLs. What is their HTTP interface?
- GET: “get a capabilities document, a feature collection, or some other thing depending on the values of ’service’, ‘request’, and other parameters”;
- PUT: undefined
- POST: “get a capabilities document, or a feature collection, *or* create, update, or delete features, or do almost anything depending on the values of ’service’, ‘request’, and other parameters”;
- DELETE: undefined
GET and POST are more or less interchangeable, depending on the particular implementation. What’s important to WxS are the other request arameters: “service”, “request”, “typename”, etc. WxS has *no* uniform HTTP interface, and is therefore *not* RESTful.”
So by this definition, our OGC WxS services do NOT appear to be restful. One might wonder if we could also advance toward a more restful architecture by eliminating capabilities documents – factoring these into additional interfaces?
-Ron
(Visit Sean Gillies’ Blog http://zcologia.com/news/)
July 18th, 2007 at 8:22 am
I’ve read over the new RESTful book, and while I [would like to think that I] understand the underlying goals of REST, I still have a little trouble with wedging “parameters” into URLs — some of their examples seem a little forced to me.
I can’t cite any of their examples now, though, as I’ve already loaned the book out. So let’s put WMS under the microscope instead. How does the output bbox gets RESTified? It seems to me that request params are best RESTed when they correspond to a bounded, enumerable list (e.g. EPSG codes or layer names) — a bbox doesn’t fit that criteria, obviously. Way not helpfully cacheable, for example.
Using the Tile Map Service seems to nicely solve this problem, but that solution is a significant departure from the WMS-style architecture of allowing arbitrary-sized response bboxes.
So, to deliberately overly simplify Ron’s question, does this imply that just eliminating capabilities documents is as insufficient means to RESTifying WxS?
-mpg
July 18th, 2007 at 9:52 am
mpg,
The Tile Map Service proposes a design that promotes caching and makes it more likely, but there is nothing inherently RESTless about using a bbox parameter. So, no, this does not imply that eliminating capabilities documents is insufficient (true, but for other reasons). First, you need to adopt a uniform interface. Stop overloading POST, and move away from service-specific methods like “GetMap” and “GetFeatures”. GET should be all that’s required.
July 18th, 2007 at 10:22 am
I’d also like to point out that the Geo-Web-REST discussion group
http://groups.google.com/group/geo-web-rest
is open to public participation.
July 20th, 2007 at 1:10 pm
The OGC is now actively considering the expression of its web services such as WFS, WRS, WMS and WCS using a REST model. It should also be noted that the OGC Web Registry Service might also be used as a means to store temporary resources (e.g. queries) subsequently invoked by GET etc. requests.
August 9th, 2007 at 7:53 pm
[…] think there’s any one clear explanation (despite some nice pieces of the puzzle here and here) available, and there has certainly been little effort to analyze the REST architecture in relation […]