Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
