ForHosting KIT · Web Scraping & Monitoring

REST endpoint naming checker

Paste a path such as /users/{id}/orders and see which naming rules it passes: lowercase, hyphen-separated words, plural nouns and no verbs. Every broken rule is reported per segment, so a review comment becomes a fix. Free in your browser.

Free
Runs in your browser
No sign-up
Your data stays on your device

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

Worked example

If you enter

Path: /v1/users/{id}/orders

You get

Segments: 4

You send one path and receive a structured verdict: which conventions passed, which failed, and a human-readable issue for every offending segment, so a review comment becomes a fix instead of a debate.

What a well-named path looks like

The widely accepted convention is that each path segment is a noun, and that collections use the plural form: /users for the collection, /users/{id} for one member of it. Words inside a segment are separated with hyphens, the kebab-case style, because underscores are harder to read in URLs and can disappear under link underlines, while camelCase mixes letter case into a place where lowercase is the norm. Version prefixes such as v1 or v2 are accepted practice and are not treated as naming errors.

What this checker tests and how it decides

The checker splits your path on slashes and ignores the query string and fragment, because those are not part of the resource naming. Each remaining segment is then tested against four rules, and every rule failure is reported separately so you can see exactly which convention a segment breaks. First, lowercase: any uppercase letter in a segment is flagged, since letter case in paths is a common source of routing bugs on case-sensitive servers.

Second, hyphenation: underscores and whitespace inside a segment are flagged, with hyphens named as the replacement. Third, plural nouns: segments that are not version prefixes and not path parameters are expected to end in a plural-looking word; a segment like /user is flagged while /users passes, and compound segments such as /user-profiles are judged by their last word. Fourth, verbs: each hyphen-separated word is compared against a fixed list of common English verbs like get, create, update, delete, fetch and login, and any match is flagged.

Path parameters in the forms {id} or :id are exempt from the noun and verb rules, because a parameter name follows different conventions than a static resource name.

What you can do with it

Settle style debates in design review

Replace opinion with a concrete list of violations when two reviewers disagree about how a path should read.

FAQ

How does it decide whether a word is plural?

With a simple, deterministic heuristic: the last hyphen-separated word of a segment must end in 's'. Version segments like v1 and path parameters like {id} or :id are exempt.

Does it check query strings or fragments?

No. Anything after '?' or '#' is stripped before the checks, since query parameters and fragments are not part of resource naming.

Which verb list does it use?

A fixed list of common English verbs seen in real APIs — get, create, update, delete, fetch, find, search, add, remove, login, register and similar. The list is deterministic and does not change between calls.

Why hyphens instead of underscores or camelCase?

Underscores are harder to read in a web address and can disappear under a link underline, while camelCase mixes capital letters into a place where lowercase is the norm. Underscores and spaces are flagged, with hyphens named as the fix.

How are placeholders such as {id} treated?

Path parameters written as {id} or :id are exempt from the noun and verb rules, because a parameter name follows different conventions from a fixed resource name. They never count against the rest of the path.

Related tools

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/dev/rest-endpoint-naming-check

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/dev/rest-endpoint-naming-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"path":"/api/v1/user-profiles"}'

const res = await fetch("https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "path": "/api/v1/user-profiles"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/rest-endpoint-naming-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "path": "/api/v1/user-profiles"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"path":"/api/v1/user-profiles"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"path":"/api/v1/user-profiles"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/rest-endpoint-naming-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "path": "/api/v1/user-profiles"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.rest_endpoint_naming_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

max_chars 2048

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Technical notes

The REST endpoint naming checker takes an endpoint path such as /users/{id}/orders and tests every segment against the conventions most style guides agree on: segments should be lowercase, words should be separated by hyphens rather than underscores or camelCase, collection resources should be plural nouns, and verbs should stay out of the path because the HTTP method already names the action.

What a good REST path looks like

REST paths name resources, not actions. The action already lives in the HTTP method — GET, POST, PUT, DELETE — so a path like /getUsers is saying the same thing twice and saying it inconsistently with the rest of the API. When a path follows these rules it becomes predictable: a developer who knows one endpoint can guess the rest of the surface without reading the documentation, and tooling such as routers, gateways and linters can be configured once and reused across every service the team ships.

Using the verdict in reviews and pipelines

The output is designed to be machine-consumable as well as readable. A typical workflow is to run the checker over every new route a service adds: paste the path during design review, catch the deviation before the route ships, and avoid the painful choice later between keeping an ugly path forever or breaking clients with a rename. Alongside the list of plain-language issues you get a checks object with one boolean per convention — lowercase, hyphenated, plural_nouns and no_verbs — plus an overall valid flag, so a CI job can fail a pull request on a single condition instead of parsing sentences. Teams also use it during API audits, feeding in routes from an OpenAPI document and collecting the segments that need attention. The same code that powers the API runs free in your browser on this page, so you can test paths interactively while designing and only spend the $0.002 per request when you automate the check inside a pipeline, a linter or an internal developer portal.

Integration use cases

Gate new routes in CI

Fail a pull request when a newly added endpoint introduces verbs, underscores or uppercase letters into the path.

Audit an existing API surface

Run the routes from an OpenAPI document through the checker and collect the segments that break your style guide.

Technical questions

What does it cost?

$0.002 per checked path via the API. It is also free to run in your browser on this page.

Why are verbs not allowed in a REST path?

Because the HTTP method already names the action. A path like /getUsers duplicates GET and drifts out of sync with the rest of the API; /users with the GET method says the same thing consistently.

What happens if I send an empty path?

The request fails with an invalid_input error explaining that a non-empty path is required. Empty input is never charged.

Read the full KIT documentation →

Run — free