WMS Practicalities and REST
Sean Gillies asked Why Does WFS Dislike the Web?. I haven’t played with WFS in years, but I’d like to explore a point raised by Allan Doyle in a the comment on Sean’s post.
Allan mentioned that adoption of a technology depends on how easy it is to get something working quickly. He was comparing KML with OGC specifications.
In the case of WMS, if it had been designed to follow REST principles I don’t think it would have been as successful because it would have been more difficult to use.
REST says that a URI identifies an abstract resource. HTTP headers are used in the request to convey metadata about the desired resource representation (e.g. Accepts), and in the response to describe the actual resource representation (e.g. Content-Type).
If you look through the WMS query string parameters some of them are metadata that describe the request, the user agent’s desired resource representation, and MIME type to be used for exceptions. Not all are used to identify the abstract resource itself:
- VERSION
- WIDTH
- HEIGHT
- FORMAT
- BGCOLOR
- EXCEPTIONS
In a sense, CRS is also a candidate for being metadata. It’s the same abstract resource regardless of the CRS used for the resource representation (but the CRS is tied to BBOX which is used to describe the resource, so it’s not clear cut).
Anyway, if all those name/value pairs had to be passed through as HTTP headers you would have needed a client other than just a plain old browser to send a WMS request. Not the best way to encourage adoption.
The value of being able to put a URI in your browser’s address bar and see what comes back cannot be understated. Instant gratification counts on the path to getting a quick result.
Update, 2006-10-22: The conversation continues at import cartography.
[tags]WMS, REST, HTTP[/tags]