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
Copyright (c) 2007 Carlo Strozzi, Some Rights Reserved
This page can be reproduced with any means, provided that each
copy retains this copyright notice.