REST-Endpunkt-Namen prüfen
Fügen Sie einen Pfad wie /users/{id}/orders ein und sehen Sie, welche Namensregeln er erfüllt: Kleinbuchstaben, Bindestriche, Substantive im Plural und keine Verben. Jeder Verstoß wird pro Segment gemeldet, so wird aus einem Review-Kommentar eine Korrektur. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Pfad
- /v1/users/{id}/orders
- Segmente
- 4
Sie senden einen Pfad und erhalten ein strukturiertes Ergebnis: welche Konventionen erfüllt wurden, welche verletzt wurden und eine verständliche Meldung für jedes beanstandete Segment — so wird aus einem Review-Kommentar eine Korrektur statt einer Debatte.
Wie ein gut benannter Pfad aussieht
Die weithin akzeptierte Konvention lautet, dass jedes Pfadsegment ein Substantiv ist und Sammlungen den Plural verwenden: /users für die Sammlung, /users/{id} für ein einzelnes Element. Wörter innerhalb eines Segments werden mit Bindestrichen getrennt, im sogenannten kebab-case-Stil, weil Unterstriche in URLs schwerer lesbar sind und unter Link-Unterstreichungen verschwinden können, während camelCase Groß- und Kleinschreibung an eine Stelle mischt, an der Kleinschreibung die Norm ist. Versionspräfixe wie v1 oder v2 sind gängige Praxis und gelten nicht als Benennungsfehler.
Wenn ein Pfad diesen Regeln folgt, wird er vorhersehbar: Wer einen Endpunkt kennt, kann den Rest der Oberfläche erraten, ohne die Dokumentation zu lesen, und Werkzeuge wie Router, Gateways und Linter lassen sich einmal konfigurieren und für jeden Dienst des Teams wiederverwenden.
Was dieser Prüfer testet und wie er entscheidet
Der Prüfer zerlegt Ihren Pfad an den Schrägstrichen und ignoriert Query-String und Fragment, da diese nicht zur Ressourcenbenennung gehören. Jedes verbleibende Segment wird dann gegen vier Regeln getestet, und jeder Regelverstoß wird separat gemeldet, damit Sie genau sehen, welche Konvention ein Segment verletzt. Erstens Kleinbuchstaben: Jeder Großbuchstabe in einem Segment wird markiert, da die Schreibweise in Pfaden eine häufige Ursache für Routing-Fehler auf case-sensitiven Servern ist.
Zweitens Bindestriche: Unterstriche und Leerzeichen innerhalb eines Segments werden markiert, wobei Bindestriche als Ersatz genannt werden. Drittens Substantive im Plural: Segmente, die weder Versionspräfixe noch Pfadparameter sind, müssen auf ein pluralartig aussehendes Wort enden; ein Segment wie /user wird markiert, während /users besteht, und zusammengesetzte Segmente wie /user-profiles werden nach ihrem letzten Wort beurteilt. Viertens Verben: Jedes durch Bindestriche getrennte Wort wird mit einer festen Liste häufiger englischer Verben wie get, create, update, delete, fetch und login verglichen, und jeder Treffer wird markiert.
Pfadparameter in den Formen {id} oder :id sind von der Substantiv- und Verbenregel ausgenommen, weil ein Parametername anderen Konventionen folgt als ein statischer Ressourcenname.
Anwendungsfälle
Neue Routen in der CI absichern
Lassen Sie einen Pull Request scheitern, wenn ein neu hinzugefügter Endpunkt Verben, Unterstriche oder Großbuchstaben in den Pfad bringt.
Stildebatten im Design-Review beenden
Ersetzen Sie Meinungen durch eine konkrete Liste von Verstößen, wenn zwei Reviewer darüber streiten, wie ein Pfad aussehen sollte.
Häufige Fragen
Was kostet die Prüfung?
Auf dieser Seite läuft die Prüfung außerdem kostenlos in Ihrem Browser.
Wie entscheidet der Prüfer, ob ein Wort im Plural steht?
Mit einer einfachen, deterministischen Heuristik: Das letzte durch Bindestriche getrennte Wort eines Segments muss auf 's' enden. Versionssegmente wie v1 und Pfadparameter wie {id} oder :id sind ausgenommen.
Werden Query-Strings oder Fragmente geprüft?
Nein. Alles nach '?' oder '#' wird vor den Prüfungen entfernt, da Query-Parameter und Fragmente nicht zur Ressourcenbenennung gehören.
Welche Verbenliste wird verwendet?
Eine feste Liste häufiger englischer Verben aus realen APIs — get, create, update, delete, fetch, find, search, add, remove, login, register und ähnliche. Die Liste ist deterministisch und ändert sich nicht zwischen Aufrufen.
Warum Bindestriche statt Unterstrichen oder camelCase?
Unterstriche sind in einer Webadresse schwerer zu lesen und können unter der Linkunterstreichung verschwinden, und camelCase mischt Großbuchstaben dort hinein, wo Kleinschreibung üblich ist. Deshalb werden Unterstriche und Leerzeichen markiert und Bindestriche als Ersatz genannt.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem 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)Beispiel-Anfrage
{
"path": "/api/v1/user-profiles"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rest_endpoint_naming_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Limits
max_chars | 2048 |
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Der REST-Endpunkt-Namensprüfer nimmt einen Endpunktpfad wie /users/{id}/orders entgegen und testet jedes Segment gegen die Konventionen, auf die sich die meisten Styleguides einigen: Segmente sollten kleingeschrieben sein, Wörter sollten durch Bindestriche statt Unterstriche oder camelCase getrennt werden, Sammlungsressourcen sollten Substantive im Plural sein, und Verben gehören nicht in den Pfad, weil die HTTP-Methode die Aktion bereits benennt.
Wie ein guter REST-Pfad aussieht
REST-Pfade benennen Ressourcen, keine Aktionen. Die Aktion steckt bereits in der HTTP-Methode — GET, POST, PUT, DELETE —, sodass ein Pfad wie /getUsers dasselbe zweimal sagt und dabei inkonsistent mit dem Rest der API ist.
Das Ergebnis in Reviews und Pipelines nutzen
Die Ausgabe ist maschinell verwertbar und zugleich lesbar. Ein typischer Ablauf: Sie prüfen jede neue Route, die ein Dienst hinzufügt — fügen den Pfad im Design-Review ein, erkennen die Abweichung vor dem Release und vermeiden später die schmerzhafte Wahl, einen unschönen Pfad für immer zu behalten oder Clients mit einer Umbenennung zu brechen. Neben der Liste verständlicher Meldungen erhalten Sie ein checks-Objekt mit einem booleschen Wert pro Konvention — lowercase, hyphenated, plural_nouns und no_verbs — sowie ein Gesamtkennzeichen valid, sodass ein CI-Job einen Pull Request an einer einzelnen Bedingung scheitern lassen kann, statt Sätze zu parsen. Teams nutzen den Prüfer auch bei API-Audits, indem sie Routen aus einem OpenAPI-Dokument einspeisen und die Segmente sammeln, die Aufmerksamkeit brauchen. Derselbe Code, der die API antreibt, läuft auf dieser Seite kostenlos in Ihrem Browser, sodass Sie Pfade beim Entwerfen interaktiv testen können und die $0.002 pro Anfrage erst dann ausgeben, wenn Sie die Prüfung in einer Pipeline, einem Linter oder einem internen Entwicklerportal automatisieren.
Integrationsbeispiele
Eine bestehende API-Oberfläche auditieren
Prüfen Sie die Routen aus einem OpenAPI-Dokument und sammeln Sie die Segmente, die gegen Ihren Styleguide verstoßen.
Technische Fragen
Warum sind Verben in einem REST-Pfad nicht erlaubt?
Weil die HTTP-Methode die Aktion bereits benennt. Ein Pfad wie /getUsers dupliziert GET und läuft dem Rest der API aus dem Takt; /users mit der Methode GET sagt dasselbe konsistent.
Was passiert, wenn ich einen leeren Pfad sende?
Die Anfrage schlägt mit einem invalid_input-Fehler fehl, der erklärt, dass ein nicht leerer Pfad erforderlich ist. Leere Eingaben werden niemals berechnet.