It's a good sign that REST is not perfect for everything. Trying to be everything to everyone is a <i>trap</i> that framework and API designers fall into. You should actually aim for making most people mostly happy, but leave some people rather bummed out.<p>(Google tech Talk on Designing an API.)
<a href="http://video.google.com/videoplay?docid=-3733345136856180693" rel="nofollow">http://video.google.com/videoplay?docid=-3733345136856180693</a><p>If your plans make everyone happy, you're probably trying to do too much.
Stateful and REST can get along pretty well, depending on what's stateful. Your resources should be stateful; they don't disappear when the request is completed. Your client-side application should be stateful too; among other things, it keeps track of the user's linking from one representation to the next. The only thing that's stateless is the request... any given request should not depend on sending some other request first, except for the case where the first request changes the state of a resource, and the second request retrieves a representation of that resource.<p>I just designed a RESTful API, and it's built upon a very stateful backend. From the client's perspective, the only hint of statefulness is that the API sends Set-Cookie response headers, and expects to get Cookie request headers back. When they're sent, performance is much better. But to keep the requests stateless, the Cookie headers are optional. If they're not sent, the URL provides enough info to recreate the backend state. This is slower, but functionally equivalent, and I think it's an approach that qualifies as being fully and correctly RESTful, while still being essentially stateful internally.
Well said. I can already envision the "technical leaders" who are passengers on the web 2.0 bandwagon reassuring themselves that there architecture decision was the correct one based off of the first 3 articles that popped up on their Google search. It's sad but true the blissful ignorance of some folks making strategic development decisions...I see it all the time in my company.
Why do client-directed messages work poorly with REST?<p>If there are any other helpful links on REST implementation, particularly working with legacy systems who are not already RESTful, that would be helpful for my start-up.<p>Otherwise, i'll just keep googling. thanks!
I feel more effort was put into creating a sensational headline than the rest of the text. There's no meat here, it tells you nothing about REST or proposed alternatives.