Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Ruby on Rails - differentiating plural vs singular resource in a REST API

I'm working on building the URLs for my REST API before I begin writing any code. Rails REST magic is fantastic, but I'm slightly bothered the formatting of a URL such as:

http://myproject/projects/5

where Project is my resource and 5 is the project_id. I think if a user is looking to retrieve all of their projects, then a respective HTTP GET http://myproject/projects makes sense. However if they're looking to retrieve information on a singular resource, such as a project, then it makes sense to have http://myproject/project/5 vs http://myproject/projects/5. Is it best to avoid this headache, or do some of you share a similar concern and even better - have a working solution?

like image 348
randombits Avatar asked Apr 10 '10 20:04

randombits


People also ask

Should REST API use plural or singular?

Plural Nouns Are Preferable, Rather Than Singular Using plural or singular nouns for defining resources has no any impact on how your API will work; however, there are common conventions that are used in all good RESTful APIs. One of such conventions is the use of plural nouns for defining resources.

Should RESTful endpoints be plural?

Using nouns for naming URIs is a REST API naming best practice, but you may wonder if plural or singular nouns are best. When should you use singular or plural nouns? In general, you should name your URIs with plural nouns.

Is API plural or singular?

The plural of "API" is "APIs".

Should URL be singular or plural?

Yes, URL could be plural, but type singular. More to say, they might be completely different words. For example GET /vehicles endpoint might return resources of type Car , Aircraft , Train , Ship , and so on. In my APIs I'm always using singular types.


2 Answers

Rails (3) has a lot of conventions when it comes to singular vs plural. For example, model classes are always singular (Person), while the corresponding tables are always plural (people). (For example, Person.all maps to select * from people.)

For routes, there's a concept of a singular resource as well as a plural resource. So if you did resource :account then you would get paths like /account for the default path or /account/edit for a path to a form to edit the account. (Note that Rails uses /account with a PUT method to actually update the account. /account/edit is a form to edit the account, which is a separate resource from the account itself.) If you did resources :people, however, then you would get paths like /people, /people/1, and /people/1/edit. The paths themselves indicate whether there can only be one instance of a given type of resource, or whether there can be multiple instances distinguished by some type of identifier.

like image 50
yfeldblum Avatar answered Nov 13 '22 14:11

yfeldblum


I agree, go with the flow. Consider how the URL forms a hierarchy.

The root of your website is where you start to access anything.

/projects/ narrows it down to only projects, not anything else. From projects you can do lots of things, /list, /index/, /export, etc... the /id limits things even further.

At each / the scope of what do becomes narrower, and I think it makes sense.

Further programming is all about arbitrary rules. Indexs starting at 1 vs 0, and so on. Anyone working with your urls will sort things out in short order.

like image 39
Tilendor Avatar answered Nov 13 '22 13:11

Tilendor