I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over an

I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over and over again in development situations: As soon as the topic of webservices comes up, someone starts crying, "REST! REST! OMG, REST!" And that's usually before they've even heard what the web service will do. It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either: 1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily. <controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial> So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.