3 ms·

He states very explicitly that his examples weren't any kind of standard, as one doesn't truly exist at that level. I think the point he was trying to get acro

by boucher 16y ago

He states very explicitly that his examples weren't any kind of standard, as one doesn't truly exist at that level. I think the point he was trying to get across, and really what a lot of people who are advocates for REST are trying to accomplish, is that in a fully realized model computers would be able to understand how to talk to each other to get information and update resource states without the need for human intervention. Clearly we are a long way from that goal, but I think it's still something worth talking about.

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).
guelo 16y ago
I don't know if it is true that that is what REST advocates are trying to accomplish. If you want to remove the human than SOAP and WSDL have gone a long way towards that goal. I always viewed REST as the opposite of that, make things simple so the developer is able to easily manipulate the data as he sees fit.

by boucher 16y ago

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).

guelo 16y ago

I don't know if it is true that that is what REST advocates are trying to accomplish. If you want to remove the human than SOAP and WSDL have gone a long way towards that goal. I always viewed REST as the opposite of that, make things simple so the developer is able to easily manipulate the data as he sees fit.