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

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.