In my simple WEB I primarily care about 3 main things :
* Addressability and Links
* Ignore Unknown Extensions
Web services needs to be addressable, when possible and practical. This will let them live in the WEB. Consumers can GET something out of such services easily. Yea, they need to also be able to update these services somehow. So lets add POST.
Now, everyone knows about PUT, DELETE and some other verbs but so far I don't quite understand how my simple WEB will benefit from PUT and DELETE, so I'll leave them out for now. Once I understand I'll welcome them in.
I'd naively assume that this is all what is needed to have all the services I've built to play with each other nicely, irrespectively of the style used to develop these services.
What really surprises me in all those debates about which style of building web services wins is that very rarely, if ever, the consumer's ability to ignore unknown extensions, aka forward compatibility, is mentioned as an absolutely key ingredient.
This is one of those things which truly makes the WEB scale, as far as the economics associated with the cost of the change and usability of client tools are concerned. In a RESTful world, the focus is on the data. This makes it easier to deal with extensions : one just extends the language.
In a not so RESTful world people are often tempted to deal with new extensions by introducing yet another method or yet another interface all the time even when it's avoidable. The lesson from a RESTful word is to focus on the data extensibility and not on the interface extensibility and interface changes.
Versioning and extensibility is a fascinating subject and it's off-topic so I'd rather chat more about it later, I'll refer to what some thought leaders out there say about it.