Your team is writing a style guide for an HTTP API. What do you specify for casing of path segments, casing of query parameter names, trailing slashes, and why?

## Why casing is a correctness issue, not taste RFC 3986 makes the **scheme and host case-insensitive** and leaves everything after them — path, query, fragment — **case-sensitive**. `https://API.Example.com` and `https://api.example.com` are the same origin; `/PurchaseOrders` and `/purchaseorders` are not the same resource. In practice some servers and frameworks normalise case and some do not, so an API with mixed-case paths produces failures that depend on which client, proxy, or generated SDK wrote the URL. A flat rule — path segments are lowercase — removes the ambiguity entirely. The separator choice between `purchase-orders`, `purchase_orders`, and `purchaseOrders` is softer, but hyphen is the long-standing web convention: it survives underlining in UIs (underscores can visually disappear), it is what humans type, and it avoids re-introducing case sensitivity through camelCase. Note that this rule is about **path segments**, not about JSON field names. ## Query parameter names are a different namespace Query strings are opaque to HTTP itself — the standard says nothing about their internal syntax beyond allowed characters. Frameworks, form encodings, and client libraries all have their own habits, which is exactly why the rule has to come from your style guide rather than from the protocol. The usual advice is to make query parameter names match the casing of your JSON payload fields, because a client working with `pageSize` in a response body and `page_size` in a query string is guaranteed to get it wrong sometimes. Whatever you pick, apply it to every endpoint, including the standard ones like paging and sorting. ## Trailing slashes and canonical form `/users` and `/users/` differ by one character and, per the URI spec, identify different resources. Real behaviour varies: some routers treat them as equal, some 404, some redirect. The failure modes when you leave it undefined are subtle rather than loud — cache entries duplicated under two keys, analytics splitting one endpoint into two rows, relative-reference resolution changing (a relative link resolved against `/users` drops the last segment, while against `/users/` it appends), and rate limits keyed by path counting each form separately. The fix is to declare one **canonical** form, almost always without the trailing slash, enforce it in the router, and respond to the non-canonical form with `301 Moved Permanently` pointing at the canonical URL. A permanent redirect is preferable to a silent internal alias because it teaches clients and caches the correct URL once, rather than accepting both forever. ## Other canonicalisation the guide should cover Since you are writing rules anyway, decide the neighbouring cases at the same time: no file extensions in paths (format is negotiated with `Accept`), no duplicated separators (`//`), a defined position for the version segment if you use one, and whether query parameter ordering is significant for cache keys — it usually is not for your server but it *is* for naive caches, so clients that build URLs deterministically get better hit rates. ## Enforcement A style guide nobody checks decays within a quarter. These rules are all mechanically checkable against an OpenAPI document — a linter that rejects uppercase or underscored path segments, trailing slashes, and extensions in paths keeps the surface consistent as the number of contributing teams grows.