I should also mention that this isn't the first time this topic has come up. It came up on the RhubarbTart mail list here: http://groups.google.com/group/rhubarbtart-discuss/browse_thread/ thread/cad6ceb58c35887a/#
And it came up previously on the Pylons list here: http://groups.google.com/group/pylons-discuss/browse_thread/thread/ 86f8abc048dd7ce7/2f0bbb4ebd354821?q=REST&rnum=1#2f0bbb4ebd354821 In the RhubarbTart list, and elsewhere is where I actually saw the suggestion for naming the actions differently depending on HTTP method. This is also the approach that was used in RhubarbTart. The conclusion seemed to be both solutions depending on the object being dispatched to. That is, having the Route able to call a specific method on HTTP verb is only really useful when the object you're dispatching to is *not* a controller. This came up in the thread Ian Bicking started on the Pylons list, because Ian was using Routes to call objects in his own framework. Those objects were not HTTP aware, so having that decision upstream in Routes made more sense. In the case where you're inside a framework though, the decision was made to go with the Rest Controller approach, as in RhubarbTart's case. As Dave Warnock mentioned on that thread, its the easiest way to do it. It's also the least effort and repetition. My personal preference for this is based on 2 key factors: 1) Scalability - If it results in huge amounts of work when your app is huge... its no good. 2) Usability - If it requires significant work just to use it... its no good. Having Routes handle it is bad in the first case due to the work involved in having a route for every action, for every HTTP verb. A controller with 20 actions, that can support 4 verbs for each would result in 80 methods. With Routes and RESTController, that's 1 Route + 80 methods. With Routes-based HTTP verb support, that's 80 Routes + 80 methods. In case 2, I consider the Routes style bad for a different reason. It affects usability by making the action names totally unpredictable. Consider that you said you wanted a POST on kb/instances to call make_instance. Perhaps another developer has it use create_instance. Your usability is affected because there is no clear rule being used for mapping actions to HTTP verbs. Some other developer working on your project with you will have to keep pulling up the routing.py file to figure out what the heck is going on. The fact that in a single sentence, I can explain to a developer how they're mapped, is a huge win for scaling a project to multiple developers, and it removes the need to keep looking at another routing file to try and figure out who gets called when. I'm in favor of putting the HTTP verb at the end of the method name for usability as well. The fact is, its easier to scan lines from the beginning, then trying to jump in. If you're looking for methods by the name of 'instances', generally its easier to scan: def instances_POST: def instances_GET: def instances_DELETE: Than: def POST_instances: def GET_instances: def DELETE_instances: Especially when you consider that when you have a large controller, you'd have many actions beginning with the same words. Scanning for just the beginning, vs in the middle is easier. Hopefully its more clear why I'm averse to extending Routes now. The most convincing reason to add HTTP verb support is for Ian Bicking's use-case, since he's calling objects that are not in controllers or even HTTP aware. - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss -~----------~----~----~----~------~----~------~--~---
