[4suite-dev] Server rules and possible REST patterns

[Uche Ogbuji]

I've been complaining about the lack of flexibility in the server config
infrastructure for a while.  It had got to be a serious pain in the
maintenance of my Web site, so I decided to give it a good hour of
meditation do see if I could come up with a simple and elegant solution:
simple enough not to involve major refactoring or to break anything. 
Elegant enough to have use well beyond my immediate needs.

I came up with a simple rule directive for config files.  Take the
following example from my Web site:

  <Rule pattern="/uche.ogbuji.net.*/"
        xslt-source="main.doc"
        xslt-transform="/uche.ogbuji.net/main.xslt"/>

This means that any time the resolved path of the request matches the
regex "/uche.ogbuji.net.*/", that an XSLT transform will be applied
using the source doc "main.doc", relative to the path, and the transform
(absolutely specified, in this case) "/uche.ogbuji.net/main.xslt".

xslt-source and xslt-transform are both optional, but one or other must
be specified.  If the source is omitted, the transform is run against
the originally matched resource.  If the transform is omitted, the
source doc is just displayed as is.

You can slso pass XSLT transform args using the optional attribute
"extra-args", which uses URL qurery syntax, e.g.

"key1=val1&key2=val2"

Not only does this solve my immediate problems, but I think it opens the
way to a Zope-like path traversal system.  If Zope's not your thing,
this is also the pattern advocated by the REST folk in Web services.

Basically, if you wanted to host a stock quote service at

http://stocksrus.com

Such that

http://stocksrus.com/services/get-quote/MSFT

Returns a stock quote for what is certainly our favorite company, then
you could do so by having a transform
http://stocksrus.com/services/get-stock-quote.xslt with the requisite
smarts, and then set up a rule

  <Rule pattern="/services/get-quote/"
        xslt-transform="get-stock-quote.xslt"/>

get-stock-quote.xslt could then extract "MFST" from the "uri-path"
param, which is still the original one, and do its thing.


Now, of course, we can make this even better, but I wanted to run
further ideas by the group first before implementing them.

If we figure this would be a common use-case (and I think it would be),
we could courteously split the path for them and pass it in as a param
to the stylesheet.

Even slicker, we could also make named groups from the pattern match
params for the XSLT.  For instance

  <Rule pattern="/services/get-quote/(?P<symbol>[A-Z]+)/?"
        xslt-transform="get-stock-quote.xslt"/>

Would cause the XSLT param with name "symbol" and value "MSFT" to be
passed to get-stock-quote.xslt in our example.

This would be a matter of about 3 lines of code to add.

Thoughts?


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston):
http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web -
http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe -
http://www.xmleurope.com/2002/kttrack.asp#themodel