In fairness to Mike, the "RR" code isn't much different from the RPC code, and that was part of the point - maybe you do lose something on tooling support with WS, but being nearer the wire/http isn't so bad ;)
Probably the most important technical programming point in the example is the get_person(resp, content) binding (albeit a fictional one) being local to the client and not part of client/server comms. Because you have the media type in the headers you can use that to drive factory style handlers/marshalling. I think what concerns tech leads and architects sometimes looking at REST over other approaches is, a) having to do the serialization lifting, b) having it creep up the code layers, where suddenly, some business logic "knows" that the data is a subset of JSON that "just" happens to drop into a spreadsheet. cheers Bill Stefan Tilkov wrote: > > > Mike, > > RPC (*bad*) is not the same as Request/Response (*ok*) > > :-) > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ <http://www.innoq.com/blog/st/> > > On Jun 17, 2007, at 6:25 PM, Mike Glendinning wrote: > > > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com>, Bill de hOra > > <[EMAIL PROTECTED]> wrote: > > > > > > Alternatively: > > > > > > h = httplib2.Http(".cache") > > > # ...authentication here... > > > resp, content = h.request("http://example.org/people/anne > <http://example.org/people/anne> ", "GET") > > ^^^^^^^^^ > > > if resp["status"].startswith("2"): > > > anne = get_person(resp, content) > > > else: > > > raise AccessException(resp, content) > > > > > > > Bill, > > > > Your example is indeed more elegant than the crufty classes that come > > as standard with Java, but still looks suspiciously like RPC. Isn't > > this supposed to be a "bad thing"? > > > > Thanks, > > > > -Mike Glendinning. > > > > > > > >
