Re: Modeling button presses that invoke server side actions via REST
Aha, I get it. URI overloading = bad 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 > -- View this message in context: http://n2.nabble.com/Modeling-button-presses-that-invoke-server-side-actions-via-REST-tp4375243p4392724.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437300
Re: Modeling button presses that invoke server side actions via REST
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 <mailto: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=2437165> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437265
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 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
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 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=2437168
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=4447&dsMessageId=2437165
