REST API Naming Conventions: The Definitive Guide (2026)

There is nothing more frustrating than integrating an API that uses /getUsers for one endpoint and /user/create for another. Inconsistent naming makes your API hard to learn, hard to use, and hard to maintain.

In this guide, we will cover the Standard REST Naming Conventions that 99% of developers expect. (And if you want to test your endpoints to ensure they return what you expect, use our API Request Tester).

1. Resources are Nouns, Not Verbs

REST is about Representational State Transfer. You are transferring the state of Resources.

• Bad: /getUsers, /updateUser, /deleteProduct
• Good: /users, /products

The HTTP Method (GET, POST, PUT, DELETE) tells the server what to do. The URL tells the server what to do it to.

2. Plural vs. Singular

This is the biggest debate in API design. The verdict? Use Plurals.

Why? Because /users represents the collection of all users.

• GET /users : Get the list of users.
• GET /users/123 : Get a specific user from the list.

If you use /user, then GET /user implies you are getting... one user? Which one? It is ambiguous.

Standard:

• /users
• /products
• /orders

3. Hierarchy and Nesting

Use nesting to show relationships, but do not go deeper than 2 levels.

• Good: /users/123/orders (Get orders for user 123)
• Good: /users/123/orders/456 (Get order 456 for user 123)
• Bad: /users/123/orders/456/items/789/details (Too deep!)

If you need to access a deeply nested resource, promote it to the root level:

• Better: /order-items/789

4. Query Parameters for Filtering

Do not create new endpoints for filtering. Use query parameters.

• Bad: /activeUsers, /usersSortedByName
• Good: GET /users?status=active, GET /users?sort=name

This keeps your API surface area small and clean.

5. Casing Conventions

URLs should be kebab-case (lowercase with hyphens). JSON fields should be camelCase.

URL:

• Good: /product-categories
• Bad: /productCategories, /product_categories

JSON Response:

{
  "userId": 123,
  "firstName": "John"
}

6. Versioning

Always version your API. Breaking changes happen. Put the version in the URL (easiest) or the Header (purist).

URL Versioning (Recommended for most):

• https://api.example.com/v1/users

Summary Checklist

1. Use Nouns for resources.
2. Use Plurals (/users).
3. Use HTTP Methods (GET, POST, PUT, DELETE) for actions.
4. Use kebab-case for URLs.
5. Use camelCase for JSON bodies.

By following these rules, you make your API predictable. Developers can "guess" your endpoints without reading the docs.