Learning to Rest
Adam Bosworth: I admit to not being a REST expert and the people commenting, Mike Dierkin and Mark Baker in particular, certainly are. They tell me I'm all wet about the REST issues. I'll dig into it. But I admit, I don't get it. I need to be educated.
I personally think that the place to start is to first tease apart the "HTTP is the one true protocol" from the "REST is the one true architecture", and then initially focus on the latter. Once done, you may come back to believe in one or both of these, but they can be addressed independently.
To draw an analogy, Java 1.0 did not have a component model. A convention of getters and setters methods corresponding to a property emerged. Getters always have zero parameters, setters typically have one.
On the web, there is an analogous component model. Resources have a GET and POST method (as well as a few others). This is not one per property, but one per resource (object). This encourages a coarse grained approach to integration - something that scales better than fine grained access.
Nothing in REST requires or precludes an equivalent to WSDL. However, nothing in WSDL today models the interaction that is typical of WSDL itself: "at this address is a document of a given type. If you GET it, you will find a strongly typed description of another resource (endpoint)".
Anybody with experience in database design will tell you that it makes sense to focus a lot of energy on optimizing reads. The web does this well.
Other principles that apply: all persistent resources have identifiers. No implicit state.
I have further thoughts posted at REST+SOAP. I'd also point to The Eight Fallacies of Distributed Computing, but alas, it has gone 404. (The concept of 404 itself is an important implication of a REST design).