4 ms·
Whilst the notion of "computers talking to each other without human intervention" sounds like a utopian ideal, I think his method is a recipe for disaster. The
by DJN 16y ago
Whilst the notion of "computers talking to each other without human intervention" sounds like a utopian ideal, I think his method is a recipe for disaster.
The domain of possible consequences of changing protocols and semantics on the fly is hugely complex. What about testing? Are we advocating that we change live systems without tests?
The author writes:
"Level 3 introduces discoverability, providing a way of making a protocol more self-documenting."
I reply:
The same way good design separates presentation, logic and data, it follows that good protocols separate data from documentation.
- hammerdr 16y ago> possible consequences of changing protocols and semantics on the fly is hugely complex Except when you assume that you're reading the semantics from each and every response. It introduces some complexity to how clients need to accept responses. However, once that part is done the changing protocol and semantics should not disrupt the system. And testing? That's not a very difficult component to test. Throw a few different 'schemas' at the HTTP client response module and then feel safe to drop that into your application. I believe you're imagining a system that is more highly coupled to the response schema. This approach is meant to remove that coupling entirely (well, except for a base uri :)) I agree that embedding <link />'s into the response is a violation of a separation of concerns. They should probably be separated in some way (HTTP headers?). However, there are precious few examples of this in the wild and we may see some creative ways to separate these (I just hope we don't go the way of XML to have a different resource to specify schema).