Modeling button presses that invoke server side actions via REST
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=4447dsMessageId=2437165
Re: Modeling button presses that invoke server side actions via REST
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=4447dsMessageId=2437165 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2437168
Re: Modeling button presses that invoke server side actions via REST
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=4447dsMessageId=2437165 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2437187
