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
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
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:
http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/
http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/00123
http://www.example.com/cgi-bin/cgiwrap/goofy/CSA/Parts/00123
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-partswhich 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=AB450and 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=AB450and 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/CSAcannot 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-partsto 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=