CGI Services Architecture
Recent Pages

Environment Variables
Template Processing
RDF Responses
RDF Messaging
URL Rewriting
File Uploads
Sample Authenticated Se ...
HTTP Cookies
Client Authentication
GET and POST Variables

Links on Twitter
CSA Home
Table of Contents



User ID

Campaigns petition banner

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/ 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":

  1. inventory.list-parts
  3. inventory.update-onhand

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


By using suitable rewriting rules in the CSA 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 file snippet:

 ^GET$    ^/Parts/*$      /inventory.list-parts 
 ^GET$    ^/Parts/        /\&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:

  1. (GET)
  2. (GET)
  3. (POST)

For example, issuing a GET request against the URL: 
will cause CSA to internally rewrite it as 
which will produce a response message containing a list of URLs to parts that are available for ordering, for instance: 
Then, if a GET request is issued against one of the returned URLs, CSA will internally rewrite it as, say, 
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 
but by using POST against it, instead of GET, the action will be rewritten by CSA as 
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 
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 
to be addressable as you will need to have the Web server configured to rewrite it into 
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/ 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 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

This Web Site is Copyright © 2007,2008,2009,2010 Carlo Strozzi, Some Rights Reserved
site map | recent changes | disclaimer