REST Naming Validator
Validate REST API endpoint paths against naming conventions
About REST Naming Validator
Checks API paths, one per line, against five naming rules and gives each rule a pass or fail badge: lowercase segments, no verbs, plural nouns, no underscores and no file extensions. Results update as you type, and hovering a badge shows what its rule checks. Use it to audit a list of routes or the paths of an OpenAPI spec before a design review.
Category: API.
Frequently asked questions
What input format does it expect?
▾
One path per line, such as /api/v1/users/{id}/orders, without the HTTP method, host or query string. Write path parameters in curly braces, because :id or literal IDs like 123 are treated as resource names and fail the Plural nouns check.
Why avoid verbs in REST URLs?
▾
The HTTP method (GET, POST, PUT, DELETE) already expresses the action. Using verbs in the path like /getUser or /deletePost creates redundancy and breaks REST semantics.
Why does /api/posts fail the No verbs check?
▾
No verbs flags any segment that starts with get, create, update, delete, fetch, add, remove, list, post, put or patch, so nouns like posts, addresses or updates fail too, while verbs outside that list, such as activate, send or any non-English verb, pass. Plural nouns only looks for a trailing s, so people or data fail; treat the results as hints.
When should I use query params vs path segments?
▾
Path segments identify resources (/users/123). Query params filter, sort, or paginate a collection (/users?role=admin&page=2). Avoid using query params to identify a specific resource.