It is much easier to be a purist about REST when working with a fairly capable client (e.g. GWT, Flex, handcoded JS with AJAX patterns, various AJAX frameworks ...) that is capable of maintaining application state.
Much of the MVC plumbing of various frameworks boils down to effective techniques for work-shifting; having the server do presentation and application state storage work on behalf of the client. This is one of those cases where people have created very beautiful solutions that, at their foundation, canonize an antipattern: the assumption that the client suffers from acute limitations in its ability to persist application state. While this is still necessarily true in certain use cases (e.g. the classic "shopping cart" example), many modern non-trivial Web applications don't have this restriction, because they can bring a lot more power to bear. In most of the applications we develop, the client is responsible for its own layout altogether, and has its own MVC patterns. We generally avoid doing the MVC lifting on the server, because it doesn't scale as well as pushing this responsibility onto the client altogether. Can't always do that, but we try! On Mon, Dec 14, 2009 at 9:44 AM, Conor Moran <[email protected]>wrote: > Hi, > this may not be the best place to post this question, but pointers > elsewhere may be satisfactory answers. > > I'm struggling with the following: > Here's the context - > - I'm running a web app in a browser. > - I was on a list of users, and I clicked an add button > - I get shown a form to enter some fields. > - I click submit > > So I'm about to create a new user for example: > ------ > POST /users .... > ------ > > After creating the user, in a typical web app I might expect to go back to > the "list of users" screen. And in an MVC (Model2), the controller would > usually handle that. > > The question is simple: how to handle that in a restlet app - following the > post, go back to the user list - where does that responsibility lie? > In general, what are the recommendations of the resty guys for doing screen > flow - does that all move to the client side? > > Most of my "rest" experience comes from dealing with ruby on rails, which I > guess is not quite purist rest. So they have a controller. > > My other question relates to a rails thing also. > > Edit screen vs. View/Show screen > So I want to show details of a user I use: > GET /users/{id} > > But they have, what seems like a hack, for getting an edit form: > GET /users/{id}/edit > (I'm not sure what corresponding Merb urls are) > > To me we are talking about one resource here, with different > representaions. But not at the level of MediaType. > The media type for my web-app might be text/html for both the view and > edit page. > > So again how best to handle this from the point of view of a rest purist? > > Any info greatfully appreciated. Perhaps I'm not looking at things in the > right way yet. > > cheers > Conor > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430295 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430340
