File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Ruby and the fly likes Plurals and Exposed Identifiers in URLs with RESTful Rails Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Ruby
Bookmark "Plurals and Exposed Identifiers in URLs with RESTful Rails" Watch "Plurals and Exposed Identifiers in URLs with RESTful Rails" New topic
Author

Plurals and Exposed Identifiers in URLs with RESTful Rails

Michael J. Makunas
Ranch Hand

Joined: Mar 11, 2002
Posts: 37
I'm not that experienced with Rails (and Ruby in general) but I'm working on an java based web api that is using the REST architectural style and I'm curious about some of the design decisions that went into the new RESTful features of Rails.

1) Plurals in URLs (i.e., www.foo.com/users/1 instead of www.foo.com/user/1). This makes sense to me and most RESTful apis seem to follow this convention, but I can't seem to find a good explanation for why. I am choosing to use plurals because semantically it just seems more correct and while URLs should be opaque to the code they should also be understandable to the human reading them.

2) Exposing identifiers (i.e., www.foo.com/users/1 instead of www.foo.com/users/myusername). In theory, I'm against exposing identifiers, but in practice it's a often a pain to deal with surrogate human readable keys. I'd prefer that the whole URL was human readable, but I'm resorting to exposing identifiers because it's just easier with the data we have.


Does anyone know if Rails chose these conventions for any particular reason? Did it just fit better with existing Rails conventions?

-Michael
Doug Hall
Greenhorn

Joined: Jul 30, 2004
Posts: 6
IDs are better for the same reason that database keys should not be an attribute - because attributes can change. This is better for the user, too, by the way, due to bookmarking.
Michael J. Makunas
Ranch Hand

Joined: Mar 11, 2002
Posts: 37
Originally posted by Doug Hall:
IDs are better for the same reason that database keys should not be an attribute - because attributes can change. This is better for the user, too, by the way, due to bookmarking.


I didn't mean use an attribute. I meant choosing between using the numeric primary key versus a human readable surrogate key (that doesn't change). Also, while you are correct, a URI should ideally not change over time, properly used 301 redirects can help.
Doug Hall
Greenhorn

Joined: Jul 30, 2004
Posts: 6
Originally posted by Michael J. Makunas:


I didn't mean use an attribute. I meant choosing between using the numeric primary key versus a human readable surrogate key (that doesn't change). Also, while you are correct, a URI should ideally not change over time, properly used 301 redirects can help.


Yes, but that's a maintenance nightmare, over time. IDs never need a redirect because they never change. Also, they uniquely identify the resource in question. Suppose you had two Tom Jones' in your organization. Do you have one URL "http://myorg.com/employees/tomjones" and the other "http://myorg.com/employees/tom_jones"? Who will know which is which, by looking at it? Yes, it's still more readable than numeric IDs, but it brings its own set of problems to the table.

Perhaps the user could just as easily do a search, and then bookmark it, if they need it more than once.

Cheers,
Doug
Eric Martinez
Greenhorn

Joined: Nov 20, 2005
Posts: 25
Pardon me if I misread but here may be a partial solution.

Rails URLs
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Plurals and Exposed Identifiers in URLs with RESTful Rails