It's a good sign that REST is not perfect for everything. Trying to be everything to everyone is a trap that framework and API designers fall into. You should actually aim for making most people mostly happy, but leave some people rather bummed out.
Unfortunately, you find none to often folks using REST to solve a wide range of problems that it isn't suited for. The point of this post is to point that fact out: just because REST exists doesn't mean you have to use it. Believe it or not, this is actually a surprise to a lot of people, especially those trying to be in some way 'Web 2.0'.
Quick EDIT: I've actually seen people try to design fundamentally stateful APIs using REST. These people admit they are stateful, and that they must be stateful, yet they continue to use REST because it's what various web companies use and promote (for totally different problems).
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.
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?
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.
The reason is simple: REST forbids a server being aware of client state. So practically, this means sessions are off limits; cookies for managing sessions are meaningless in such a world.
To send an event to a client, though, means the server must have some sort of awareness of the client. Otherwise, it wouldn't know to send the client a message in the first place.
So, can you have events in conjunction with REST? Sure. Just realize once you do that, your application isn't 100% RESTful. It's RESTful and... RESTless I guess :)
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.
(Google tech Talk on Designing an API.) http://video.google.com/videoplay?docid=-3733345136856180693
If your plans make everyone happy, you're probably trying to do too much.