Hello, > 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 +1
The PUT request should be used to set the whole state of the resource. So, you can use the POST on your widget resource (POST means to act on the state of the resource), or as said Tim, use the PUT request, but on another resource. Best regards, Thierry Boileau > > --tim > > On Wed, Jan 13, 2010 at 4:32 PM, kevinpauli <[email protected] > <mailto:[email protected]>> 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=2437165> > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437265
