Cool URIs in a RESTful World

Posted by Thomas Bandholtz on Apr 08, 2008 07:48 AM

Community

SOA

Topics

Semantic Web

Tags

Mashups,

RDF,

Standardization,

Collaborative Technologies,

W3C,

Web 2.0,

REST

What might this be: "envisioned as a decentralised world-wide information space for sharing machine-readable data with a minimum of integration costs"? Is this about REST? Nope. According to SWEO, it is about the Semantic Web. Cool URIs will help making this way. So it might be worth looking whether RESTful SOA URIs can also be "cool".

The Semantic Web Education and Outreach (SWEO) Interest Group came to the end of it's charter end of March. One final product was a W3C Note about Cool URIs for the Semantic Web. Can URIs be cool? This refers to an early article by Tim Berners-Lee from 1998 (not yet a "Sir" at that time) :

"What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them."

Today's cool URIs are not that simple. In 2005, after a lasting debate on "the range of the HTTP dereference function" (httpRange-14), the W3C Technical Architecture Group (TAG) finally decided that "if an HTTP response code of 200 (a successful retrieval) was given, that indicated that the URI indeed was for an information resource, but with no such response, or with a different code, no such assumption could be made", as summarized by TBL in 2005. The current SWEO Note refers to a more detailed posting by Roy T. Fielding.

a) If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource;
b) If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;
c) If an "http" resource responds to a GET request with a 4xx (error) response, then the nature of the resource is unknown. 

Fielding is almost a synonym for the REST architecture. However, the httpRange-14 decision has been hardly recognized in RESTful SOA, e.g. neither in Mark Bakers article on the "hypermedia constraint", nor in Anne Thomas Manes' "REST is about Resources". URIs are Uniform Resource Identifiers, a fundamental concept for REST in general. The SWEO Note solely adds "a practical guide for implementers of the RDF specification" as an exemplification.

RDF stands for Resource Description Framework, which "allows users to describe both Web documents and concepts from the real world - people, organizations, topics, things - in a computer-processable way. Publishing such descriptions on the Web creates the Semantic Web." The co-occurrence of human-readable Web documents - also called: "information resources" - and computer-processable descriptions or semantic concepts raised ambiguities about what HTTP URIs identify . Does http://www.example.com/people/alice represent Alice's nicely designed home page, or some RDF encoded metadata about Alice? Could it as well be a vCard, a FOAF record, or some HR dataset following any company-specific scheme?

Such questions are out of scope of the protocol-independent URI syntax , it's up to the HTTP protocol to provide content negotiation as a solution. HTTP clients may pass over the preferred data formats and languages along with the target URI in the request header, and the content provider should serve these settings. The SWEO Note provides a solution that implies one individual URI for each data format, plus one "generic". This allows for direct linking to a specific preference among the multiple presentations, if required, while the generic URI will redirect to one of these, according to the given "accept" settings in the HTTP request at execution time. A more detailed best practice for the Apache HTTP Server has also been published.

RESTful SOA may argue that this mainly fits for a provision of fix document files. A dynamic SOA server can easily implement this "generic" URI concept without any redirection, just by rendering the content in the requested format on demand. This view satisfies content provision, while the redirection architecture better supports linkage and reference. It also leverages resource management and governance, be it in the Semantic Web, or in RESTful SOA. And may be these two application areas are not so distinct from each other.

• Older >