The Web Inside
What happens if you apply the REST design pattern to its logical conclusion?
by Randolph Kahle
September 15, 2006
Ajax is changing the nature of Web applications and placing new demands on server-side code. Proposed solutions and server-side development platforms perpetuate current code-based thinking. This article examines a new, different, and proven approach based on RESTful resource-oriented development that eliminates emerging complexities by leveraging the principles that have made the Web successful.
Before Ajax, servers were responsible for the creation and delivery of complete HTML pages displayed in Web browsers. For each request, a traditional Web application extracts information from a database, binds it to Java objects, performs business processing, and creates an HTML page.
What if the Web's boundary extended beyond the server? What if the Web reached into the data tier and eliminated your need to understand and manage data types? You would have a set of Web application surfaces that extended across the network, from the Ajax client-side to the server-side and through the layers of your application to the data (see Figure 2).
In this type of system, your server-side application would become a set of mappings from external URL addresses to server-side resources. If these mappings extend to the data, then your objects and code would disappear. Just as Web pages can be composed from related bits of information, server-side software can compose a resource representation from the core data and return a result. How can you implement this system? Is it a practical way for you to develop your server-side applications?
Using the Web for Software Dev
To enable software construction using principles from the Web, you must adopt a single important concept: Use URI addresses to identify all the elements in your system. These elements include resources, services, information channels, and program code. To create a URI address, such as a URL, you use a scheme, such as http: or ftp:, and an address. You must augment schemes that are focused on small-scale, in-memory operations within contexts appropriate for application software to create URI schemes that work well between computers, such as http:. For example, a channel: scheme identifies information channels, and a resource: scheme identifies specific resources by name. With internal URI addressed resources providing your core application entities, you can construct a system by mapping external URL addresses to internal resources. Figure 3 illustrates a simple example of this approach.
In Figure 3, the external URL /index.html is mapped to an internal resource identified by file:/src/index.html, or a file residing within the file system.
A more sophisticated system might generate the resource representation for /index.html using an XSLT transform of an XML file. Figure 4 shows you which mappings are required to implement this approach:
In Figure 4, the external /index.html resource is mapped to a functional program that uses XSLT to transform an XML document into the requested resource. Here is the full URI for this transformation:
active:[email protected]:/src/[email protected]:/src/layout.xsl
This URL uses the active: scheme, which you can use to specify functional programs within a URI.
The active: scheme depicted in Figure 5 specifies a function or service and a series of named arguments. Each argument references a URI that provides the value. This recursive use of URIs creates a tree-shaped set of related resources that together result in a resource representation computation.
Back to top