3 REST API Naming Tools, Compared Honestly

You are adding an endpoint and the question is what to call it. Should it be /getUserOrders or /users/{id}/orders? Plural or singular? Does cancelling an order become a POST to /orders/{id}/cancel, or a PATCH that sets a status field?

The conventions here are well established and widely documented, which is exactly why the inconsistency in most real APIs is so irritating. Nobody disagrees about the rules — use nouns, prefer plurals, let the HTTP method carry the verb, hyphenate, avoid deep nesting. People simply do not have the rules in front of them at the moment they are naming something, so the API accumulates a /getUserOrders next to a /users/{id}/orders and neither gets renamed because both are now public.

How to judge a REST naming aid

Does it produce a name or explain the rule? Reading the convention again and applying it are different acts, and only one of them takes two seconds.

Does it suggest the method? Path and HTTP verb are one decision, not two — the verb is what stops the path needing one.

Does it handle actions that are not CRUD? Cancel, publish, approve, and retry are where conventions genuinely disagree.

Is it opinionated? A tool that offers you five valid options has not helped with consistency.

The comparison

Facts checked August 2026; plans can change.

Zuplo naming conventions guide

Zuplo’s guide is the most structured treatment of the decisions rather than just the rules — plural versus singular, casing, nesting depth, versioning placement — which makes it the best of the three if you are establishing a convention for a team rather than naming one endpoint.

It is a document. Having read it, you still make each individual naming decision yourself, and the drift that produces inconsistent APIs happens between reading and applying.

DreamFactory endpoint naming best practices

DreamFactory’s post is the most practical, working through the core rules with the reasoning behind each: nouns rather than verbs because the HTTP method already specifies the action, hyphens and lowercase to avoid ambiguity, and nesting limited to about one level.

Again, it is reference material. Excellent for settling an argument in a code review, silent at the moment you are typing a route.

REST API best practices repo

A GitHub repository of API naming and design conventions has one significant advantage over an article: you can vendor it, link it from your contributing guide, and point at a specific line in review. Free and open source, it becomes a shared reference rather than something each developer read once.

It reflects its authors’ preferences, as all such lists do. Where the community genuinely disagrees — action endpoints being the classic case — you are adopting one position rather than seeing the trade-off.

REST Endpoint Namer

Ours turns the rules into output. Enter a resource name and an action and it returns a consistent RESTful endpoint path along with a suggested HTTP method, following common API naming conventions — so the decision takes two seconds and comes out the same way each time regardless of who is naming it. It runs entirely in your browser.

The limitations are real. It follows common conventions, and REST conventions are not universal: your organisation may deliberately use singular resources, a different versioning scheme, or an RPC-style action pattern, and the tool does not know that. It also cannot see your existing API, so it will not warn you that you already have a route which conflicts, nor design your resource model — deciding that “cancellation” is a resource rather than an action on orders is an architectural judgement no namer will make for you.

Which one to pick

• If you are setting a team convention from scratch, read Zuplo’s guide first.
• If you want the reasoning to cite in a code review, DreamFactory’s post explains it well.
• If you want a reference living in the repo, vendor the best-practices list.
• If the convention is settled and you just want the name, use ours.

How to do it with REST Endpoint Namer

1. Open the REST Endpoint Namer.
2. Enter the resource and the action you need.
3. Check the suggested path and method against your existing routes for conflicts.
4. Deviate deliberately where your house style differs, and document why. More developer tools are in the tools directory.

You might also need

• API Versioning Strategy Advisor — for the versioning decision that sits above the path.
• OpenAPI Spec Visualizer — for seeing the shape of the API the names are building.

Frequently asked questions

Is there a free REST naming tool that doesn’t need an account?

Yes — the three references above are free to read, and ours requires no account because the site has no signup at all.

Should REST resources be plural or singular?

Plural is the dominant convention — /users for the collection and /users/123 for one member — because it reads consistently across both cases. What matters more than the choice is applying it uniformly; a mixed API is worse than either convention consistently applied.

How do I name an endpoint for an action that is not CRUD?

This is where conventions genuinely diverge. Common approaches are a sub-resource POST such as /orders/123/cancellation, or treating the action as a state change via PATCH. The HTTP semantics specification defines what each method means, which is the right basis for deciding — pick one pattern and use it everywhere.

Final thought

Settle the convention once, then generate names rather than recalling rules. Inconsistent APIs are almost never the result of disagreement — they are the result of nobody having the rule to hand.

Try the free REST Endpoint Namer