Well-designed URIs make an API feel intuitive to navigate. The dominant convention is hierarchical, noun-based paths that use plural nouns for collections, such as /users/123/orders/456, where each segment narrows the scope from collection to item to related sub-collection. Plural nouns make it obvious whether you are addressing the whole set or a single member, and they read naturally when the resource itself implies plurality, as users and orders do. Following this rule consistently means clients can guess URIs from the API's domain model rather than consulting documentation.
Verb-based paths are discouraged because the HTTP method already declares the action. Saying DELETE /users/1 is more idiomatic and shorter than /deleteUser/1, and it keeps the URL focused on the resource. Query parameters, on the other hand, are the right place for everything that does not identify a specific resource: filtering, sorting, pagination, and search live in the query string so that paths remain clean and stable. For example, /users?role=admin&sort=name&page=2 keeps the resource hierarchy in the path and the slice of results in the query string. Depth should be moderated; even though nested paths like /users/123/orders/456 are valid, deeply nested hierarchies become hard to maintain and rarely reflect access patterns well—often a flatter URI plus filtering is clearer.
Versioning is the other major URI-design decision. The two common approaches are versioning through a path prefix, such as /v1/users, and versioning through the Accept request header, such as Accept: application/vnd.api.v1+json. Path versioning is the simplest to implement and to debug, since the version is visible in the URL and easy to route on. Header versioning keeps URIs clean and lets the same resource live at one address across multiple versions, which can be more flexible, but at the cost of slightly more client complexity because the version is no longer part of the path.