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&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:
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.
I’m seeing the growth of POX, with AJAX and XMLHttpRequest currently doing the most pushing. If ECMAScript for XML (E4X) starts getting traction, it’ll be a slam dunk (and hopefully similar grammars will make it into other favorite languages).
I sure hope some specified, official format, like Atom, will do this instead of RSS 2.0.
Atom may be too little, too late — something that does 10-20% more than RSS isn’t enough to make people switch when RSS 2.0 is already so well established. I’d prefer POX+XLink+xml:id, personally, but to continue the HTML analogy, remember that HTML came first, and the W3C came much later.
What exactly does using RSS 2.0 gain you over using an arbitrary XML language?
If there is to be a more widely used common data format for the Web, the barest minimum I would expect is a means to identify the identifiers of the Web, i.e. URIs. Personally I’d opt for something semantically richer 😉
Pingback: Read/Write Web
Pingback: Quoderat » More on RSS as the HTML for data …