[
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 -
Scalability:
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>
</ex:person>
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.
Jan
> /r$
>
--
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com
|
