Developer tools

REST API Endpoint Namer

Type a resource, an optional parent resource and the actions you need, and get a table of conventional, versioned REST endpoints ready to copy into your docs.

Naming tips

  • Prefix with a version, like /v1, so you can evolve the API later.
  • Use plural, kebab-case nouns for resources: /shipping-addresses, not /shippingAddress.
  • Let the HTTP method carry the verb; keep nouns out of it except for custom actions.
  • Keep nesting to one level deep; prefer query parameters over /a/{id}/b/{id}/c chains.

Generated endpoints

MethodPathPurpose

Everything is generated locally — nothing is sent anywhere.

🔗

Follows REST convention

Plural kebab-case nouns, no verbs in the path, and clean nested resources when you need them.

🛠

Handles custom actions

Not everything is CRUD — add a named action like /invoices/{invoiceId}/send when you need one.

📋

Copy-ready table

One click copies every method and path as plain text, ready to paste into API docs or a spec.

How to use the REST API endpoint namer

Describe your resource once and get a full, consistent set of endpoints back.

  1. Name your resourceType a singular resource name, and a parent resource if it's nested under another one.
  2. Pick the actionsCheck the standard CRUD actions you need, or add a custom action for anything else.
  3. Copy the tableRead the generated methods and paths, then copy the whole table as plain text.

REST naming conventions explained

Good REST endpoint names are boring on purpose: predictable, pluralized nouns paired with the HTTP method that already tells the client what will happen. Following the same small set of rules across every resource in an API makes the whole surface easier to guess correctly, even for endpoints a developer has never seen before.

Plural, kebab-case nouns

/shipping-addresses reads naturally for both the collection and a single item at /shipping-addresses/{id}, and kebab-case avoids casing debates in URLs.

No verbs, except as actions

The method already says GET, POST, PUT, PATCH or DELETE. Reserve extra path segments for genuine non-CRUD actions, like /send or /cancel.

Shallow nesting

One level of nesting, such as /customers/{customerId}/invoices, stays readable. Deeper chains usually mean a query parameter would work better.

Version from day one

A /v1 prefix costs nothing up front and gives you a safe way to introduce breaking changes later without disrupting existing clients.

REST API endpoint namer FAQ

Common questions about naming, nesting and custom actions.

Why use plural nouns like /invoices instead of /invoice?

A plural collection name reads naturally for both the list endpoint (GET /invoices) and a single item within it (GET /invoices/{id}), keeping the base path consistent across every action on that resource.

Why avoid verbs in the path?

REST relies on the HTTP method to express the action, so GET, POST, PUT, PATCH and DELETE already say what is happening. Adding verbs like /getInvoices or /deleteInvoice duplicates that meaning and breaks the convention that a path names a resource, not an operation.

How should I handle an action that is not simple CRUD?

Model it as a sub-resource or a clearly named action segment on a specific item, such as POST /invoices/{invoiceId}/send. This keeps the verb-free convention for standard CRUD while still giving non-CRUD operations a predictable, resource-scoped place to live.

How deep should resource nesting go?

Most APIs stay readable with one level of nesting, such as /customers/{customerId}/invoices. Beyond that, paths get long and fragile; it is usually better to fetch the child resource directly with a query parameter, such as /invoices?customerId=123.

Is my data saved or sent anywhere?

No. Every endpoint is generated locally in your browser from what you type, and nothing is stored or transmitted.

Explore more free tools: GraphQL Query FormatterSQL Query BuilderAll Features