Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that:

www.site.com/controller/action/params/?vars -> would route to ->

class controller(requestHandler):

    def get_action(self, *params, **vars):
        #do something
        self.write(response)
    def  post_action2(self, *params, **vars):
        #.... and so on ....

I don't get it. Your example is what Tornado looks like::

  class LoginHandler(RequestHandler):
      def get(self):
          self.render('login.html')
      def post(self):
          self.set_secure_cookie(self.get_argument('username'))
        self.redirect('/')

Having one class per URL is very common and perhaps it's more than a decade of Python web programming but I like that. Makes for neat code.

The one class per action pattern helps with async calls and callbacks. The handler class has methods for each HTTP method plus the callbacks it needs.

That would get really messy in a controller-with-multiple-actions pattern as the controller classe now has a lot more methods in a single class: all the HTTP methods it handles plus the callbacks for all of them.

i dont agree with you, i would rather have a controller with multiple actions, rather then "controller"/requestHandler per action, because in most cases you want the controller to handle all the actions of a page, rather then one action.

Having controller per one action would put overhead on the code lines you write.

Im a PHP developer who uses Tornado and I recently wrote a PHP micro framework that works like tornado's controllers where rest verbs were the only publicly (uri) accessible methods