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 ]

Rich Salz 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.
> How so?  I can see why the single point is better for integration -- 
> you only change one message posted to one URL, as opposed to one 
> message posted to "n" URL's -- not worse.  And I don't see the 
> difference in scalability at all.  Can you explain?
- The example task is to get the address of a person -


With the single-service approach I have something like this:

POST /myService

person-id: 778
method-name: getAddress

...service returns address....

In order to understand the message, a system component must understand 
the particular semantics of the message content. The consequnce is that 
an intermediate cache cannot decide if the message is cacheable unless 
it knnows the application semantics. Consequnce: you cannot build 
application semantics independent caches.

With REST you'd have:

GET /persons/778

server responds:
Content-Type: application/rdf+xml

<ex:person rdf:about="">
   <rdfs:label>Joe Smith</rdfs:label>
   <ex:address>77 Park Av., Laketown</ex:address>

 HTTP semantics define GET responses as cacheable, so any generic HTTP 
intermediary knows it can cache the response.

That improves scalability, IMHO.


I do not have time right now, will address the integratability part later.


>     /r$

Jan Algermissen
Consultant & Programmer


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

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