The Architecture of URL Paths: Why Kebab-Case is the Industry Gold Standard

Muhammad Irwanto

3 min read

·

Apr 28, 2026

--

Listen

Share

If your API documentation looks like a naming lottery, your developer experience (DX) is already failing. Consistency isn’t just about aesthetics; it’s about reducing cognitive load. It’s time to standardize your endpoint paths.

In large-scale systems, endpoint paths often evolve organically. Developers create endpoints based on personal preference or the naming convention of the specific module they are working on. Without a shared architectural guideline, you end up with a fragmented API surface where the client-side developer has to guess if the endpoint uses PascalCase, snake_case, or a mix of everything.

Press enter or click to view image in full size

In many legacy systems or teams without strict design standards, you will frequently see a mixture of styles within the same API:
• /api/retailprices (No separator)
• /api/VehicleStatus/Read (PascalCase)
• /get_product_prices (snake_case)
• /api/USER-LIST (Upper-kebab)

The Disadvantages of the Approach

1. High Cognitive Load: Every time a front-end developer consumes your API, they have to verify the casing style. It’s unnecessary mental overhead.
2. Searchability Issues: Mixed-case URLs are harder to index, log, and monitor effectively in distributed tracing tools.
3. URL Encoding & Case Sensitivity: While URLs should be treated as case-insensitive by servers, many frameworks treat /User and /user differently. Inconsistency here leads to frequent 404 errors.
4. Poor DX: It signals a lack of maturity in the engineering culture.

Press enter or click to view image in full size

The Alternative: The Kebab-Case Standard

Kebab-case (hyphenated-lowercase) is the widely accepted standard for RESTful API resources (used by Google, Amazon, and Microsoft). It is human-readable, URL-friendly, and removes all ambiguity.

• Better: /api/retail-prices
• Better: /api/vehicle-statuses
• Better: /api/product-prices

You can use this code below to convert your PascalCase class into kebab-case string, or visit this github repository:

[return: NotNullIfNotNull(nameof(origin))]
public static string? ToKebabCase(this string? origin)
{
    if (string.IsNullOrEmpty(origin))
    {
        return origin;
    }

    // Use a regular expression to identify and process parts of the string outside of curly braces
    return Regex.Replace(origin, @"[a-zA-Z]+(?=(?:[^{}]*{[^{}]*})*[^{}]*$)",
        match => Regex.Replace(match.Value, "([a-z])([A-Z])", "$1-$2").ToLower());
}

Comparison: Casing Styles

kebab-case:/api/user-orders — ExcellentHigh (Recommended) snake_case:/api/user_orders— GoodModerate PascalCase:/api/UserOrders— ModerateLow (Discouraged) camelCase:/api/userOrders— ModerateLow (Discouraged)

When the “Common Approach” Fits

Honestly? It rarely fits in modern greenfield development. However, there is one scenario where you might justify deviating:

• Legacy System Interop: If you are building a wrapper around a legacy system or an existing proprietary API that enforces a specific case-sensitive path structure that you cannot change. Even then, I recommend implementing a mapping layer to expose a clean, kebab-case facade to your users.

When Kebab-Case Fits

Kebab-case is the superior choice for 99% of API designs:

• RESTful APIs: It aligns perfectly with the noun-based resource structure of REST.
• • Public-Facing APIs: It is the most “readable” format for external developers.
• • Log Analytics: Hyphens provide clear delimiters, making it easier to write Regex or patterns to aggregate API metrics in tools like Datadog, Splunk, or Prometheus.

Final Consideration

As software engineers, we are responsible for the interface — not just the implementation. Your API endpoint structure is the interface that your frontend team, mobile team, and external clients have to interact with every day. By choosing kebab-case, you are making a deliberate decision to favor clarity and predictability. It is a low-effort, high-impact architectural choice that removes the “guessing game” from your API.

If you’re C# developer and you‘re looking for a library to speed up your daily work, you can see this repo: sumapap.