A tasteful variation on the RESTful Rails routes | Hacker News Reader

A tasteful variation on the RESTful Rails routes

icelab.com.au

30 pointstimriley15 comments

Pretty sick of people calling this RESTful... anyway, for those who do care about URL design more than their model CRUD, I've been using this with success: https://gist.github.com/970992

It removes flawed tradition and makes it a lot easier to see which routes matter vs. which ones exist just because rails added them. Note that the example routes also avoid new/edit routes since this app actually generates those views on the client side.

Beyond that, plural or not, that's pretty much going to add zero value. Some people claim that the URL is an interface. While it might be, that's usually the lack of a better UI and a poor excuse to call something usable. I'll happily hide my URL bar when I can and rarely care to even write a proper URL by hand. Not because I can't but because I'm not a machine.

Now I do care about nice URI design but that's for me to care about, not the user. More and more I see people linking to things through shortening services anyway... so when do you really read a URL before following it? Probably never. Things like this are just for developer sanity.

So if you're going to bother writing a library, make it easier to express URIs that won't need to change and are explicitly designed, rather than worry over developer vanity and hiding details behind poorly thought out CRUD that people like to pretend is REST.

I'm unconvinced. A singular resource name implies a singleton resource, e.g. /account, which is a singleton as far as the user is concerned. It's a simple pattern: singular > singleton, plural > collection.

Github does all kinds of non-standard stuff like putting the requested response format in the URI path instead of as an extension, e.g. "http://github.com/api/v2/json/repos/search/ruby+testing. So just because Github has done it, doesn't mean everyone else should too.

It makes no difference whether the response content type is in the URI as a path segment or as an "extension"; both are wrong from a pure ReST perspective.

Who said anything about REST?

Well the original article is ostensibly about ReST. So when you claimed that Github did some other things in a "non-standard" way I assumed you were referring to ReST.

Github has also remedied that in their 3rd version of the API. For example, their issues comments collection is exposed through the URI /repos/:user/:repo/issues/comments/:id

That could be related to their decision to use only JSON as the interchange format though.

Would /job/ redirect to /jobs/ ? Otherwise it breaks removing the last part of path in the address bar, or clicking the up button in Konqueror (at least when I was using it a few years ago; I don't know if it still has an up button by default).

BTW I think in the case of pull requests, pulls isn't a nice shortened version of pull_requests, and pull_requests is just too long for how often it's used. GitHub still uses the plural form for issues. https://github.com/kriszyp/rql/issues/14

Thanks, that's a very good point. I'll make it happen.

https://github.com/icelab/tasteful-routes/issues/1

I don't care much about /jobs/123 vs /job/123

my biggest problem with the default crud routes is create/update url mapping. if create fails, it will usually re-render edit, but now you have it over non-edit url. create actually shares url with index, and so if controller doesn't support index you might have a page with edit form and url at the top that can't be resolved for a GET request. so if you do Control-L, Enter you get error page, duh!

I think a better default would be for create to map to same url as new, and update same url as edit

A gem to take 1 character off of your model routes?

Without the gem, making your RESTful routes have the right plural/singular forms takes something like this:

    match 'jobs' => 'jobs#index', :via => :get, :as => :jobs
    match 'jobs' => 'jobs#create', :via => :post
    resources :job, :controller => 'jobs', :except => [:index, :create]

For a bunch of resources, it's certainly much easier to use the one-line `tasteful_resources` helper instead.

It's your call as to whether you think this is worthwhile, but we think that these small details matter, even in URLs.

I don't understand why changing the way rails does its routing provides any benefit to the application or its code base.

Any rails helpers that depend on default resource routes will break or require special decorators to maintain consistency. Experience rails developers entering your code base will be confused why their newest partial didn't just work, and will have to learn in one form or another the customization this gem provides.

So now you maintain an entire "system" on top of rails for the benefit of reversing the pluralization of models, something a well placed monkey patch could do with less lines and overall maintenance.

All of this of course is limited to my opinion, your miles may vary. Generally, I've learned from those more experienced that quick and dirty will get you farther, faster, than building things you will never use.

I don't get it. What's the benefit over the standard /jobs/:id? Something about how jquery works?

No, just that it reads better.

Am I correct in thinking that this breaks ActiveResource?

Reply on news.ycombinator.com