Beautiful Architecture

Applied Resource-Oriented Architecture

Recently, I built a resource-oriented system on the rearchitecture work my company did for the Persistent URL (PURL) system. The original PURL^[27] implementation was done close to 15 years ago. It was a forked version of Apache 1.0, written in C and reflecting the state of the art at the time.^[28] It has been a steady piece of Internet infrastructure since then, but it was showing its age and needed modernization, particularly to support the W3C TAG’s 303 recommendation and higher volumes of use. Most of the data was accessible through web pages or ad hoc CGI-bin scripts because at the time, the browser seemed like the only real client to serve. As we started to realize the applicability of persistent, unambiguous identifiers for use in the Semantic Web, life sciences, publication, and similar communities, we knew that it was time to rethink the architecture to be more useful for both people and software.

The PURL system was designed to mediate the tension between good names and resolvable names. Anyone who has been publishing content on the Web over time knows that links break when content gets moved around. The notion of a Persistent URL is one that has a good, logical name that maps to a resolvable location. For example, a PURL could be defined that points from http://purl.org/people/briansletten to http://bosatsu.net/foaf/brian.rdf and returns a 303 to indicate a “see also” response. I am not a network-addressable resource, but my Friend-of-a-Friend ...