Bill de hOra wrote: > 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 ;)
This is the point that I try to stress about using HTTP. It can be a good thing, but in the end, if you write code with the right layers of separation, it doesn't have to be the only choice, and there are things to be gained from not using HTTP, such as QOS and latency reduction. > 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. This is why I believe it's important to have a working type system within the software at appropriate layers. Each element of the system should have enough type information to make sure that it can validate its assumptions about the data it is using as early and as completely as possible. Gregg Wonderly
