ForHosting KIT · Websites auslesen & überwachen

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
Nutzen Sie es über WebAPIE-MailTelegramApp bald
Wenn Sie eingeben
Pfad
/v1/users/{id}/orders
Erhalten Sie
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.

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.

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.

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.

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

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

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"}'
{
  "path": "/api/v1/user-profiles"
}
{
  "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.

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

max_chars2048
HTTPCodeBedeutung
401unauthorizedDer API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
402insufficient_balanceIhr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
404unknown_typeUnbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
429rate_limitedZu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

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.

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.

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.

Vollständige KIT-Dokumentation lesen →