[
Lists Home |
Date Index |
Thread Index
]
> 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
|
