[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Exposing resources/services vs hiding implementationdetail

• To: Michael Champion <michaelc.champion@g...>,xml-dev@l...
• Subject: Re: Exposing resources/services vs hiding implementationdetails
• From: Leigh Dodds <leigh@l...>
• Date: Tue, 05 Apr 2005 23:27:58 +0100
• In-reply-to: <e3a5cb2c0504050907453ad7f4@m...>
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...> <4252B1D7.8090707@t...> <e3a5cb2c0504050907453ad7f4@m...>
• User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Michael Champion wrote:

> On Apr 5, 2005 11:42 AM, Jan Algermissen <jalgermissen@t...> 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.

Cheers,

L.

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

• References:
  • RE: What Does SOAP/WS Do that A REST System Can't?
    • From: "Marc de Graauw" <marc@m...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Bill de hÓra <bill.dehora@p...>
  • Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Jan Algermissen <jalgermissen@t...>
  • Re: Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>

• Prev by Date: Re: Exposing resources/services vs hiding implementation details
• Next by Date: Re: Exposing resources/services vs hiding implementationdetails
• Previous by thread: Re: Exposing resources/services vs hiding implementationdetails
• Next by thread: Re: Exposing resources/services vs hiding implementationdetails
• Index(es):
  • Date
  • Thread