I’m so glad that we synchronized on the similarities between our two approaches. I’m just still not sure I understand his “coupling complaint” against REST.
He writes;
However, I believe that there is a danger by adopting the resource-oriented view that Mark’s approach suggests. Identifying a resource through a URI and applying the semantics of an HTTP verb on it (e.g., GET URI) is good for retrieving state, as the web demonstrates. My worry about this approach is that there is a coupling of an identifier (the URI), an interface (HTTP verbs), and the state on which these verbs operate. The approach may work for the web but as we attempt to build large-scale, distributed applications that do not involve the human factor, we may get complex networks of references between the states of resources containing references to other resources which, in turn, may lead to brittle applications. We use the same argument against the resource-oriented WS-RF approach, which of course introduces lifetime management, renewable references, etc. behaviours into the picture (borrowed from the distributed-objects world).
I’m trying hard to understand the coupling Savas speaks of there, and its purported problems. I’d say that there exists a weak form of coupling between the identifier and the interface via the URI scheme, and I consider that a feature; I don’t think you can late bind identifiers to representations – which provides a whole lot of simplicity and scalability – without it.
I’m not sure what he means by the coupling between the identifier, the interface, and “the state on which these verbs operate”. As I see it, even with a “processThis” approach, there’s that same form of coupling; some document is processed, and though its semantics are independent of previous documents (unlike WS-RF), the resulting state change in the server component is a function of the just-processed document, all previously processed documents, and any initial state that existed before that point. For example, if I was firing a bunch of documents to a processor which adds integers, then although the messages have identical semantics – “process this 1” – the state of the processor changes as a result of each one.
Savas, if that doesn’t describe what you’re talking about, can you elaborate please? Perhaps an example would help.