CGI Services Architecture: URL Rewriting

CGI Services Architecture

Recent Pages: Environment Variables
Handling Concurrency
Template Processing
RDF Responses
RDF Messaging
URL Rewriting
File Uploads
Sample Authenticated Se ...
HTTP Cookies
Client Authentication
Links: www.strozzi.it on Twitter; CSA Home; Table of Contents
Advertising
Session
Campaigns

URL Rewriting

Some parts of CSA have been designed specifically to try and implement parts of the REST architectural style. The relevant CSA features represent the way I understand the underlying philosophy, and they do not necessarily provide a correct implementation. I leave this judgement to others.

REST mapping

An important REST-related feature of CSA is its capability to expose to clients a "logical representation" of CSA Web applications and resources. This is done through a URL rewriting mechanism, based on AWK regular expressions. For more details see the etc/rest.map file distributed with CSA. Here I will give only a few examples to show what this mechanism can be useful for.

Let's say we have a CSA Web application (let's call it "inventory"), that deals with querying a remote repository of items and update the number of units on-hand of a particular item (or part). The "inventory" application is made up by three "methods":

inventory.list-parts
inventory.show-part
inventory.update-onhand

According to the non-RESTful CSA-RPC model, the three methods can be invoked through URLs similar to the following:

http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.list-parts
http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.show-part&partid=00123
http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.update-onhand&partid=00123

By using suitable rewriting rules in the CSA rest.map file, we can present to clients a logical representation of such URLs, in terms of entities (names) rather than methods (verbs). Here is the relevant rest.map file snippet:

 ^GET$    ^/Parts/*$      /inventory.list-parts 
 ^GET$    ^/Parts/        /inventory.show-part\&partid= 
 ^POST$   ^/Parts/        /inventory.update-onhand\&partid=

Given these rewriting rules, and depending on the HTTP method used, the previous URLs will thus become addressable also as:

(GET) http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/
(GET) http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/00123
(POST) http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/00123

For example, issuing a GET request against the URL:

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/

will cause CSA to internally rewrite it as

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.list-parts

which will produce a response message containing a list of URLs to parts that are available for ordering, for instance:

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/00123/ 
 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/AB450/ 
 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/A0015/

Then, if a GET request is issued against one of the returned URLs, CSA will internally rewrite it as, say,

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.show-part&partid=AB450

and the relevant inventory entry (part detail) will be shown to the client. On the part detail page, an edit form for the on-hand value will be present, with a button to submit it through a POST operation. The URL associated with the POST will still be in RESTful format, for instance

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/AB450/

but by using POST against it, instead of GET, the action will be rewritten by CSA as

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.update-onhand&partid=AB450

and this time it will result in an update of the on-hand value of part AB450.

The URL rewriting facilities provided by CSA are rather flexible, and it should be possible to rewrite almost anything into anything else.

The part of the URL up to the CSA front-end program name, that is

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA

cannot be rewritten by CSA, which has no control over it, but only by the Web server program, if the one being used provides URL rewriting facilities ( Apache does). That is, if you want a URL like

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA?0=inventory.list-parts

to be addressable as http://www.example.com/Inventory/ you will need to have the Web server configured to rewrite it into

 http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/

and then CSA will be able to apply its own rewriting rules, as shown.

In addition to the above site-wide rewriting rules, each CSA application can provide its own. The latter, if present, are sought for in $CSA_ROOT/lib/rest.map and are handled much the same as the site-wide ones, with the exception that the application name ( inventory) is now implied, so it MUST NOT be specified again in the rules. For example, the site-wide rewiting rules previously shown, if written in the application-level rest.map file need to be modified as follows:

 ^GET$    ^/Parts/*$      /list-parts 
 ^GET$    ^/Parts/        /show-part\&partid= 
 ^POST$   ^/Parts/        /update-onhand\&partid=

Trackbacks (0) | New trackback | Print