& XSLT >  If you decide to go the POST route, what you want to avoid  are exposing 
>  controller URIs (all client requests go to one URI). At least give the 
>  things of interest (the equivalent of your objects in your domain model 
>  or your table rows in your physical data model) visible identity.

As a long-time fan of federated naming (XFN), I'm sympathetic to this 
approach.  In some deployments, however, we've seen that it's not 
appropriate:
	- If you're already POSTing the query, why require clients to
	  know "n" URL's rather than one?  Why "split up" the mesage?
	- There are concerns about directly exposing things like table
	  rows; I barely know SQL syntax, but I thought stored
	  procedures and views were the way to go
	- Concerns about exposing more than a single "generic" URI
	  to outside parties; more choke-points to manage, more things
	  to forward/change when deployments or architectures change
	  internally

We often talk about exposing a single generic URI and using 
content-based routing to achieve "service-oriented NAT," and find that 
customers like this approach.

	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>