John Cowan wrote, > Miles Sabin scripsit: > > As far as network protocols and software are concerned, abstract > > Resources do no work at all. What matters in a retrieval context is > > that there be a functioning server that's capable of returning a > > response, maybe with a response entity, maybe without. > > Cash registers don't really add up the prices of items bought, they > only grind their gears. But they don't really grind their gears > either, they only obey the laws of physics. > > It's always possible to eliminate abstractions from a description of > practice. That's not really what's going on here. I'm not denying that other abstractions are legitimate or useful. I'm simply observing that above network protocols and software there are multiple incompatible abstractions. And I'm suggesting that rather than trying (and failing, repeatedly) to make them mutually consistent we just live with the multiplicity. Nothing breaks at the level of network protocols and software if we do that, and so long as this lower layer is described in a way which is neutral wrt the higher level abstractions we have a common framework despite our disagreements. Hence my objection to REST being hard-wired into the Web Architecture and the use of REST terms in base-level specifications. That's just poor layering IMO, and only likely to lead to yet more interminable wrangling. Cheers, Miles
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format