[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...>
• Subject: Re: Exposing resources/services vs hiding implementationdetails
• From: Jan Algermissen <jalgermissen@t...>
• Date: Tue, 05 Apr 2005 19:07:54 +0200
• Cc: xml-dev <xml-dev@l...>
• In-reply-to: <e3a5cb2c0504050907453ad7f4@m...>
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...> <4252B1D7.8090707@t...> <e3a5cb2c0504050907453ad7f4@m...>
• Reply-to: algermissen@a...
• User-agent: Mozilla Thunderbird 1.0 (Macintosh/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, 
>
scalability: you do not get caching possibilities with single-service+POST

integratability: if the domain model behind the service changes (due to 
integration or evolution) and this (naturally) propagates to the service 
API conversation with former clients becomes impossible because they do 
not know the new semantics (and API). With REST you at least *can* have 
a conversation and the server can for example provide the client with 
the neccessary  information to adapt (e.g. transformation code can be 
send accross to  transform the new schema into the old one).

IMHO, this capability of REST to handle domain model evolution without 
having to re-program existing clients makes it a very interesting choice 
not only for internet-scale/outside-firewall situations but also for  
common enterprise IT (behind the firewall) systems.
 

>especially
>since one has to add "security" to the list of necessary properties
>for a Web application in today's world.
>  
>
Can you point me to a good starting point for the 'security issues 
list'? Limited experience keeps me from argueing about this point, 
admitedly.

Jan

>-----------------------------------------------------------------
>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>
>
>
>  
>


-- 
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com

• Follow-Ups:
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Leigh Dodds <leigh@l...>

• 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: XML Query, XSLT, XPath and related specifications - last call
• Next by Date: Re: Exposing resources/services vs hiding implementationdetails
• Previous by thread: Re: Exposing resources/services vs hiding implementation details
• Next by thread: Re: Exposing resources/services vs hiding implementationdetails
• Index(es):
  • Date
  • Thread