Hi, Tim's idea is a good one. You might also consider having a "review queue" resource to which you POST widgets that are ready to be reviewed. GET on this resource would be a natural way to expose the widgets that are ready for review to the reviewers.
Rhett On Jan 13, 2010, at 3:47 PM, Tim Peierls wrote: > It sounds like you have one URI for two distinct resources: the contents of > widget 123 and the submission status of widget 123. Why not just use two URIs? > > /myapp/widget/123 // for the "contents" of widget 123 > /myapp/widget/123/status // for the status of widget 123 > > --tim > > On Wed, Jan 13, 2010 at 4:32 PM, kevinpauli <ke...@thepaulis.com> wrote: > Hi, I'm embarking on a new web app and have chosen RESTlet. Now it is time > to begin designing the interactions, and something sorta basic about REST > has me stumped. I am trying to figure out the best way to mediate the > impedance mismatch between REST and OO without falling down the slippery > slope of RPC. Let me give a (contrived) example. > > Widgets can be created, modified, and then submitted for review. > > To modify a widget with the id of 123, the user does a PUT to > /myapp/widget/123 and the new form data. The restlet repackages all the > form data as a POJO and hands it off to the logic layer for validation and > subsequent persistence, invoking WidgetManager.update(widgetPojo). > > To submit a widget for review, the user clicks a button, which also does a > PUT to /myapp/widget/123, but now the form data just has has one field, a > status of "submitted" (I don't send all the form data again, just the field > I want to change). However, now the restlet needs to invoke a different > business object, WidgetStateManager.updateState(123, "submitted"), which is > going to do some other specialized processing in addition to updating the > state. > > So, in an attempt to be RESTful, I've modeled both the widget updates and > the submit for review action as PUTs to the same URL, /myapp/widget/123. So > now, in my restlet, I need to figure out what a particular PUT request means > in terms of the business functions, and therefore which business function(s) > to invoke. > > But how can I reliably determine which function to invoke merely by > inspecting the values in the form data? It is SOOO tempting to pass an > "action" field along with the form data, with a value like "update" or > "submit for review" in the PUT! Then my restlet could do a switch based on > that value. But that of course is not RESTful and is nothing more than > dressed up RPC. > > It just doesn't seem safe or scalable to infer what button was clicked just > by examining the form data with a bunch of if-then-elses in the restlet. I > can imagine dozens of different actions that could be taken on a widget, and > therefore dozens of if-then-elses. What am I missing here? My gut tells me > I haven't modeled my resources correctly, or I'm missing a particular > resource abstraction that would help. > > -- > View this message in context: > http://n2.nabble.com/Modeling-button-presses-that-invoke-server-side-actions-via-REST-tp4375243p4375243.html > Sent from the Restlet Discuss mailing list archive at Nabble.com. > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437165 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437187
