As I’ve mentioned before, REST offloads complexity from the protocol (HTTP) to the content (XML). That makes REST look simple as long as you focus only on the protocol, but RESTafarians cannot get away forever with leaving the content format for data unspecified.

REST works with the existing document web because we have HTML to hold everything together — in other words, we have a standard protocol and a standard format. What’s the equivalent of HTML for the RESTful data web? RDF? XML Topic Maps? POX (Plain Old XML) with XLink? Nope — love it or hate it, I get the impression that it’s going to be RSS 2.0. People are starting to push the boundaries of RSS in serious ways, and so far, it’s not breaking. I have trouble imagining how we’re going to use RSS to encode information (say, a data record) rather than just pointing to information, but I’m ready to be surprised.

On the topic of RSS, I noticed that Open Search has introduced some RSS 2.0 extension properties (confusingly labelled OpenSearch RSS 1.0 Specification) to handle result paging, which was at the centre of another of my REST design questions. The spec is admirably minimalist, introducing only three new child elements of channel: openSearch:totalResults, openSearch:startIndex, and openSearch:itemsPerPage. That way, a RESTful web app can return (say) results 65-98 of 200,000 in a reasonably portable way:

<rss version="2.0" xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/">
 <channel>
  <title>Example.org search: REST</title>
  <link>http://www.example.org/search?q=REST&amp;start=65</link>
  <description>Search results for REST.</description>
  <openSearch:totalResults>200,000</openSearch:totalResults>
  <openSearch:startIndex>65</openSearch:startIndex>
  <openSearch:itemsPerPage>33</openSearch:itemsPerPage>
   ...
 </channel>
</rss>

This is exactly the way people are supposed to use Namespaces (nicely done!), I’m impressed that they require including the GET URL that can reproduce the search results. It would be even better, I think, if A9 added just two more elements to their RSS extensions:

  <openSearch:previousLink>http://www.example.org/search?q=REST&amp;start=32</openSearch:previousLink>
  <openSearch:nextLink>http://www.example.org/search?q=REST&amp;start=99</openSearch:nextLink>

That way, I would be able to page through the results without having to know how to construct query GET URLs for that particular site.

I like RSS for syndication, but it wasn’t exactly what I had in mind for general data handling (I would at least have liked a common attribute identifying URLs, like xlink:href); then again, HTML wasn’t exactly what I had in mind for Hypertext in 1990 either, and it took me two years to stop being sniffy and start working with it. I won’t wait that long this time.