@christianv this is an attempt to dry up some of the route definitions. The top `scope` method can be used to bundle up the repetitive `/api/my` in the majority of our routes, as well as enforce the format to be json by default, further DRYing the cookie cutting route bootstrapping. The `as` parameter is used to keep things harmonious with the other route helper definitions above, which is used by url_helpers in rails views (not sure if we are using any anywhere in our code but always good to keep things compatible).

The `resource` piece is an attempt to sell the idea of using some more RESTful endpoints, by using some of Rails conventions for dealing with RESTful resource routing. For something like a calendar event, I can imagine it being used in many places throughout different front end page views, wouldn't it be nice to have it behave like a RESTful resource (and maybe even consider wiring up angular-resource to it?). There's also more benefits later on if you want to start accepting multiple event creation at once (`resources` keyword), and so forth.

I don't think every route should be using the `resource` keyword, just endpoints that behave like resources (tasks is another good example, that is defined in a very repetitive way above). 

Of course, if you ever want to see all the nitty gritty details of routes, there's `rake routes`