Don’t get me wrong. Exposing an HTTP GET interface and supporting query string parameters is a wonderful thing for building mash-ups and bookmarking, but it’s only the tip of the iceberg to being truly RESTful.
FeatureSever is software that allows users to obtain information about geographic features using a RESTful API. Here’s a few examples of the kind of URLs FeatureServer exposes:
“1” is a feature identifier (e.g. my house). Note that these URLs aren’t terribly RESTful, although they are easy to use and understand. Why aren’t they RESTful? The URL isn’t suppose to indicate the nature of the representation (the R in REST), in this case Atom, KML, GML and JSON, each of which has its own designated mime media type. This goes against the URI Opacity best practice. Each of these URLs represents the same resource (my house), but they can represent it differently in GML, KML and even a old-fashioned HTML page would be possible.
If FeatureServer were more RESTful, there would only be one URL:
And the mime-type request would move to the HTTP request header “Accept”. Here’s a version that requests feature “1” in KML:
GET /featureserver.cgi/scribble/1 HTTP/1.1
So why didn’t they do it this way? Setting the “Accept” HTTP request header is impossible to do in an HTML <A> tag even though it performs an HTTP GET. It’s also impossible to set via the <FORM> tag. Specifying the mime type using the URL is simply easier and easier wins the day.
As software is written to understand more alternative media types, especially machine-readable types like RSS, this may start to cause problems. If there are two URLs for “my house”, then which URL do I bookmark? Firefox might bookmark the “.html” version, but my Map reader might prefer the KML version. Two URLs for the same thing.
How would I determine how popular “my house” is on the web by finding backlinks? I’d need to put this in the Google box:
link:http://example.com/featureserver.cgi/scribble/1.[Every media type here]
That’s not an ideal way of keeping track of things.