If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server s

If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side. If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations. Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.