Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

I think Rails developers seriously, seriously fetishize those six actions to the detriment of several other concerns.

First, not everything your app will do is conveniently understandable in terms of resources, just like not everything code does is conveniently understandable in terms of operators. We have, thankfully, largely killed operator overloading and replaced it with functions. Why regress on function naming in our controllers? This is really a paypal_callback, not a PUT on the Paypal "resource", which doesn't even exist and if it did would tie across authentication, billing, and stats subsystems. (What does a PUT on Paypal even mean, anyhow?)

I also get hives when I think about including Rails default routes -- which are programmer-optimized, not user-optimized -- in publicly visible places, where they will get picked up by search engines and seen by copy/pasting users. example.com/categories/1/cards/5 is a part of your user interface... and it sucks. example.com/bingo-cards/holidays/halloween is superior in just about every conceivable way.

It seems you misunderstand how the Rails system works. But let me explain.

1) You can certainly have a paypal_callback method, if you choose. That's talking about the carrier, though, not the action. Presumably that callback means something specify. Like completing an order or authorizing a credit card check. Modeling your domain deeper like that makes it easier to follow and understand. But if you're either unable, unwilling, or uninterested in expanding your domain like that, you can certainly also just map paypal_callback to a controller with a action that corresponds to that.

2) example.com/bingo-cards can certainly work well if you know you entire namespace in advance. This can be true for things like CMS'es, but it's rarely true for user account based applications. For example, if your product has a /help section that's supposed to do something specific and a user creates another entity called "help" you're in trouble.

The /categories part establishes a namespace. So you can have both /categories/wonderland and /tags/wonderland and they can peacefully co-exist.

The ID part doesn't have to be a number either, but again it comes back to namespacing. If you don't use unique identifiers, there can only be one thing named halloween and it has to refer to the same entity. When that's true, go ahead, knock yourself out. Lots of Rails application is having a taste of two worlds with ID including permas, like /users/5-sam -- that's nice for SEO and still you can have two Sams.

Hope that clears up the confusion.

I think our difference of opinion here is largely a function that you run a web application which sprouted a CMS and I run a CMS which sprouted a web application.

> example.com/bingo-cards/holidays/halloween is superior in just about every conceivable way.

...ever A/B-tested that hypothesis? ;)

I've found that I rarely need additional actions outside of the canonical six, though I do firmly believe we need a 'delete' action analogous to 'new' and 'edit'. Sticking to those actions like DHH mentions, allows me to stop worrying about where something belongs and get things done. Considering that most apps are simply fancy CRUD guis over a db ... it works very well.

Routing is decoupled from those actions. You are not forced to use 'example.com/categories/1/cards/5', you can have (in this case) the #show action mapped to 'example/foo/some_card' if you want.

Reply on news.ycombinator.com