OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Exposing resources/services vs hiding implementationdetail

[ Lists Home | Date Index | Thread Index ]

Michael Champion wrote:

> On Apr 5, 2005 11:42 AM, Jan Algermissen <jalgermissen@topicmapping.com> wrote:
>> the extreme of providing a
>>single poiunt of access (e.g. http://foo.org/myService ) to POST
>>everything to just doesn't seem to cut it when it comes to scalability
>>and integratability.
>>But maybe I misunderstand your point.
> My point is to ask for evidence to support that assertion, especially
> since one has to add "security" to the list of necessary properties
> for a Web application in today's world.

* Caching proxies will cache the results of a GET but not a POST. A 
client can similarly cache the results. This can all happen
independently of the particulars of the message exchange. This can
directly help scalability, especially if I've got a service like Akamai
deployed between me and my users.

* If I can retrieve a representation of a resource via GET, then one
method of integration is the simple link.

* You're free to manage your URL space, changing its structure without
impact to me by applying simple HTTP rewrites, and a 302. No need for
me to learn a new request format/location/etc.

* Fine-grained security is much easier to achieve when you can identify 
the resources under control with their own URIs. Web servers allow 
security constraints to be applied based on request method -- you don't
have to hide it all behind POST, see for example, [1].

* Auditing of your application usage can be as simple as mining your
web server logs.



[1]. http://norman.walsh.name/2005/02/22/limitexcept


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS