Mixing REST API plural and singular for different resources?

Question

Plural form for REST api is more natural and more used e.g. /api/users or api/users/123.

But for some resources is not natural e.g.:

• /api/login - log in exact one user
• /api/profile - get profile of logged user

this resources never will be used for more that one object/model in my app.

On the other hand I read that mixing plural and singular form in resources names is not good practice (http://pages.apigee.com/web-api-design-ebook.html).

So I consider what to do:

1. use singular for all
2. use plural for all (with some stupid forms like /api/logins)
3. to be inconsistent and use plural for almost all resources expect some special resources like /api/login or /api/profile which always used with one object/model.

What is the better approach?

Answer 1

There are no strict guidelines for defining a RESTful API, but what I read the most is that common sense should have the upper hand.

Therefore, option 3:

to be inconsistent and use plural for almost all resources expect some special resources like /api/login or /api/profile which always used with one object/model.

is the most logical. You should always be able to guess the URL when you think "I need resource X, how would this URL look like"?

Answer 2

I'm not saying I prefer plurals, but if you are going with plurals you could reconcile your special singulars this way:

GET /api/forms/login is the HTML login form. Using this perspective, login is an ID of just one form in a collection of forms.

POST /api/forms/login is where the login form is submitted.

GET /api/users/{id}/profile retrieves the profile of the indicated user. This works for a lot of cases but does not work for anonymity sites where the identity of the user should remain hidden even while looking at their profile, which might leave out their user ID and real name.

GET /api/profiles/{id} decouples the profile entity from the user ID and would work for an anonymity site.

Alternatively, you could write GET /api/users/current/profile or GET /api/sessions/current/profile which omits a specific ID like in your post since the server will reply with the content relevant to the current user.