4 A sustainable REST architecture for HTTP servers 4.1 A generic architecture to support change

As REST is an architectural style rather than an actual architecture, several implementations are possible. Our goal is to maximize the longevity of our server implementation and to minimize the amount of effort needed to react to change. Hence, we will discuss a generic architecture that implements the REST architectural style and that is easily extensible for various use cases in which data and metadata have to be exposed in a sustainable way, which is compatible with the current data infrastructure in the cultural heritage domain. The UML diagram in Figure 4 shows the different components and their relation. We will follow the route of a message exchange through this architecture.

Step 1: Sending the request The client creates the request, which consists of a URL that identifies a resource and an HTTP method specifying the action. To the request message, it adds metadata such as its preferences regarding the content type. This request is sent to the HTTP Server through the HTTP protocol.

Step 2: Receiving and parsing the request Inside the server, the RequestHandler is listening for incoming requests and receives the Client’s HTTP request, which it parses into components: method, URL, and metadata.

Step 3: Identifying the resource The RequestHandler asks the Resolver to map the URL it extracted from the message to an internal identifier of the resource. This fully decouples the external URL from the internal naming

Figure 4: The Client exchanges HTTP messages with the RequestHandler, the entry point to the HTTP Server and interface to the Data Server. The multiple implementations of RepresentationGenerator provide support for different representations. Internal applications, such as a Collection Management System, continue to access the Data Server directly. scheme, ensuring that both can evolve independently.

Step 4: Retrieving and/or modifying the resource The RequestHandler uses the internal resource identifier to retrieve the correct resource from the ResourceManager. If the issued HTTP method demands a modification, and the user is permitted to perform it, then the underlying database is updated first.

Step 5: Generating the representation Based on the Client’s content type preferences indicated in the HTTP message, the RequestHandler selects a RepresentationGenerator out of the available generator list (which can be extended). A specific generator, for instance the HtmlGenerator, takes the Resource and serializes it as a Representation in a specific format. If the Resource contains references to other Resources, their internal identifiers are converted to URLs by the Resolver and then embedded in the representation.

Step 6: Sending the representation The RepresentationGenerator sends the representation back to the Client. The Client can now follow links in this representation, in response to which the cycle starts again at Step 1.