Best Practices for Naming REST API Endpoints

REST APIs are like bridges between different software applications, allowing them to communicate smoothly. While they are super useful, building and putting them into action can be a bit tricky. So in this blog we will cover few naming conventions which we need to keep in mind as it will make things much easier. It helps speed up the process and gets things rolling right away.

Summary of what we'll learn in this blog.

Do's Don'ts
Use Nouns for Resources Avoid Verbs in Endpoint Names
Use Plural Nouns for Collections Avoid CamelCase or Underscores
Use Hyphens for Readability Avoid Pluralizing Single Resources

Here are some good ways to name your REST API endpoints:

  1. Use Descriptive Names:

    • Naming your endpoints well makes it easier for others to understand and use them. It's like giving a clear sign on a road.
  2. Choose Nouns, Usually Plural:

    • Think of your resources (like data or information) as things. Naming them with nouns (names of things) helps keep things organized.

    • For example, instead of saying "getUsers", just say "users". It's like saying "show me users" when you make a request.

    • The only time you'd use a singular noun is if it's really obvious. For example, for a special kind of user, you might say "admin" instead of "admins".

  3. Keep It Simple and Easy to Guess:

    • Imagine someone new to your API trying to guess how to find something. Use full words instead of short forms or codes. For example, say "first-name" instead of "fn".

    • If a lot of people use a short form for something (like "ids" for "identification numbers"), it's okay to use that.

  4. Show Hierarchy with Slashes:

    • Think of your API like a tree. The main part is like the trunk, and then you have branches and leaves. The slashes "/" show how things are connected.

    • For example, if you want to see an account under a client under a user, you'd say "/users/client-id/accounts/account-id".

  5. Use Dashes to Separate Words:

    • When you have more than one word in an endpoint, use dashes. It's like putting spaces in names to make them easier to read.

    • So instead of "firstName" or "first_name", you'd write "first-name".

  6. Use Small Letters:

    • In web addresses, capital and small letters are not the same. Using small letters all the time makes sure there's no confusion.
  7. Stay Away from Weird Symbols:

    • Symbols like brackets, angle brackets, and special characters can make things complicated. Stick to simple letters and numbers.
  8. Skip File Extensions:

    • You don't need to add things like ".HTML" to the end of your URLs. It just makes things longer and more complex.

    • Instead, you can use something called the Content-Type to say what kind of file it is.


  • Good Endpoint: /users

    • This means "give me a list of users".
  • Good Endpoint: /users/123/first-name

    • This means "give me the first name of the user with ID number 123".
  • Not So Good Endpoint: /Users/123/FirstName

    • It's not as good because it uses capital letters, which might cause problems.
  • Good Endpoint: /users/client-id/accounts/account-id

    • This shows the hierarchy of users, clients, and accounts.
  • Good Endpoint: /users/ids

    • This is fine because a lot of people know "ids" means "identification numbers".

Why This Matters:

Naming your API endpoints in a clear and consistent way makes your API much easier to understand and use. It's like giving good directions on a map. This helps not only new developers but also the people who will be using your API. It keeps things organized, reduces mistakes, and makes it easier to grow and add new features.

So, remember, good names make a big difference!

Learn More

  1. A practical guide to data collection with OpenTelemetry, Prometheus and Grafana
  2. Beginner's Guide to HTTP Methods and Status Codes
  3. Flask and SQLAlchemy: Better Data Management

Please let me know if there's anything else I can add or if there's any way to improve the post. Also, leave a comment if you have any feedback or suggestions.


Up next