A resource is a conceptual object identified by a URI. A representation is a transferable representation of that resource at a particular point in time.

For example, /users/42 can identify a user resource. Its JSON representation may contain id, name, and email.

The URI identifies the resource; JSON is merely one representation. The same conceptual resource could theoretically be represented as JSON, XML, HTML, or another media type.

Avoid exposing implementation details such as /getUserFromMongoCollection. Prefer resource-oriented identifiers such as /users/42.

Prefer stable, meaningful nouns.

Good examples:

• GET /users
• GET /users/42
• GET /users/42/orders
• POST /orders

Avoid RPC-style paths such as GET /getUsers, POST /createUser, or POST /deleteUser when standard HTTP semantics can express the operation.

Use plural collection nouns consistently. Path parameters normally identify a specific resource. Query parameters are better for filtering, sorting, pagination, projection, and optional retrieval behavior.

Do not put sensitive information such as passwords, access tokens, or secrets into URLs because URLs can be logged, cached, stored in browser history, or transmitted through intermediary systems.

Nested routes are useful when a child resource is strongly scoped by a parent relationship.

GET /users/42/orders communicates that the requested order collection belongs to user 42.

However, excessive nesting makes APIs difficult to navigate. A route such as /companies/1/departments/2/teams/4/users/9/orders/3 is usually a sign that resource identifiers should be independently addressable.

A useful rule is to nest when the parent-child relationship is central to the operation and shallow routes when resources have independent identity.