tag:blogger.com,1999:blog-7821856652257554779.post317375765686377519..comments2023-10-22T12:47:47.534+02:00Comments on Andrzej on Software: REST: Some tips and implementing "Forgot your password?"Andrzej Krzywdahttp://www.blogger.com/profile/06399276063142826365noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7821856652257554779.post-20446229941581548992008-10-29T21:22:00.000+01:002008-10-29T21:22:00.000+01:00Personally I think that you have misunderstood RES...Personally I think that you have misunderstood REST (the general theory) for the Rails-specific implementation of REST. Theoretically REST simply suggests that you have a uniformly addressable resource (the 'RE' in REST) upon which you invoke state changes by trigger events (actions, the 'ST' part). There is <I>absolutely nothing incompatible</I> between REST and a reset_password custom method.<BR/><BR/>If, however, you want to cut down on the number of urls related to a password reset you could use the HTTP verbs in an interesting way. It would certainly seem that the actual change of the password could be PUT:/user/4/password while the entry screen gould be GET:/user/4/password and the email request to get that page would be POST:/user/4/password. By so doing you have conceptually turned the password into something like a resource while still strongly relating it to the resource to which it belongs.<BR/><BR/>And I agree with <B>steve eley</B> regarding the Superuser solution. The idea that you are creating a new Role or Privilege is much more straightforward than something akin to a user subclass (even at the resource level).Andy Vanassehttps://www.blogger.com/profile/12115203660815920942noreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-10827721817981968692008-10-27T14:37:00.000+01:002008-10-27T14:37:00.000+01:00@opensas"for example, how would you handle an "apr...@opensas<BR/><BR/>"for example, how would you handle an "aprove/close/reject invoice" event? may be an update on an invoice_state resource?"<BR/><BR/>I did something similar in one of my projects by creating Approvement, Rejection and other such resources. I even had model classes for them, as it was really important to know when all the things happened and by whom.<BR/><BR/><BR/>"and if I have to recalculate some averages? a resource "salary_average" which can be updated..."<BR/><BR/>I'm not sure I understand...<BR/>Are you asking how to implement actions that calculate something in order to return a result?<BR/>Having a salary_average resource sounds good here. You could POST a department id and just return the numbers for the given department.<BR/>So, you would have:<BR/><BR/>salary_average/4<BR/><BR/>which could go to the salary_averages_controller, CREATE action.<BR/><BR/>def create<BR/> Department.find(params[:id]).salary_average<BR/>end<BR/><BR/>Makes sense?Andrzej Krzywdahttps://www.blogger.com/profile/06399276063142826365noreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-55845855928383670032008-10-27T14:31:00.000+01:002008-10-27T14:31:00.000+01:00@bragiYes, I'm thinking about it :)@sebanThanks!@s...@bragi<BR/><BR/>Yes, I'm thinking about it :)<BR/><BR/>@seban<BR/><BR/>Thanks!<BR/><BR/>@steve<BR/><BR/>That's a good suggestion, thanks. To be honest, I'm not sure what exactly was needed for my friend's "superuser feature". I just wanted to highlight that having a Superusers resource is a possible option.Andrzej Krzywdahttps://www.blogger.com/profile/06399276063142826365noreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-60060552509849241972008-10-26T17:00:00.000+01:002008-10-26T17:00:00.000+01:00interesting article, I haven't jumped onto rest ye...interesting article, I haven't jumped onto rest yet, but I'm still having troubles thinking rest resources... I feel like I have to "scale down" my application or something like that...<BR/><BR/>for example, how would you handle an "aprove/close/reject invoice" event? may be an update on an invoice_state resource?<BR/><BR/>and if I have to recalculate some averages? a resource "salary_average" which can be updated...<BR/><BR/>ps: I agree with steve, having a prileges or permission resource makes much senseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-2167074075681773142008-10-24T16:59:00.000+02:002008-10-24T16:59:00.000+02:00I think your password solution is spot-on, but the...I think your password solution is spot-on, but the superuser example seems a bit too specific. Unless there's a Superuser model that attaches to users by composition, I feel like "Create Superuser" implies something different than what you have -- it feels more like making a new superuser out of whole cloth, not changing a privilege on an existing user.<BR/><BR/>Assuming a simple "edit the User resource" is deemed insufficient, I probably would have handled that one with a Privilege resource. Then you can create, show, modify, or delete privileges as necessary, and lock it down with whatever authorizations are appropriate. Superuser would be just another privilege.Anonymoushttps://www.blogger.com/profile/18042837993663587290noreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-19506828355855431902008-10-24T16:36:00.000+02:002008-10-24T16:36:00.000+02:00Interesting solution. I like it!Interesting solution. I like it!sebanhttps://www.blogger.com/profile/11509789500803876481noreply@blogger.comtag:blogger.com,1999:blog-7821856652257554779.post-75321463701180308772008-10-24T15:14:00.000+02:002008-10-24T15:14:00.000+02:00Now only port this solution to restful_authenticat...Now only port this solution to restful_authentication :)Bragihttps://www.blogger.com/profile/12109437004322472888noreply@blogger.com