Controller Endpoint Naming Convention

Tags: , , , ,

I have a controller endpoint and I need help with the naming convention.

Basically, the endpoint is supposed to find a customer by their Id/Email (which is sent in the url of the request). Thus I need to have two endpoints, one for users/{id} and one for users/{email}.

The issue is, the above wouldn’t work as the routes are exactly the same.

What I have done is I have replaces the users/{email} route with:

users/get-by-email/{email} and kept the get by id route as: users/{id}



It seems you are creating some kind of REST API for interacting with stored data. In REST, the information you are handling is called a resource. You have users resource and emails resource. My suggestion would be that you could have a users/{id} endpoint and emails/{email} endpoint, which would return the necessary information. Further, you could also have users/{id}/emails, which would return the email addresses of a specific user etc. The purpose of naming the endpoints wisely is to aim for clarity and self-explanation.

The most in-depth discussion: Fielding, R. Representational State Transfer (REST)

Source: stackoverflow