Vérificateur de nommage d'endpoints REST
Collez un chemin comme /users/{id}/orders et voyez quelles règles de nommage il respecte : minuscules, mots séparés par des tirets, noms au pluriel et aucun verbe. Chaque règle enfreinte est signalée par segment, et le commentaire de revue devient une correction. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Chemin
- /v1/users/{id}/orders
- Segments
- 4
Vous envoyez un chemin et recevez un verdict structuré : quelles conventions sont respectées, lesquelles échouent, et un problème lisible pour chaque segment fautif, de sorte qu'un commentaire de revue devienne une correction plutôt qu'un débat.
À quoi ressemble un chemin bien nommé
La convention largement acceptée veut que chaque segment de chemin soit un nom, et que les collections utilisent le pluriel : /users pour la collection, /users/{id} pour l'un de ses membres. Les mots à l'intérieur d'un segment sont séparés par des tirets, le style kebab-case, car les underscores sont plus difficiles à lire dans les URL et peuvent disparaître sous le soulignement des liens, tandis que le camelCase mélange les majuscules là où les minuscules sont la norme.
Les préfixes de version comme v1 ou v2 sont une pratique acceptée et ne sont pas traités comme des erreurs de nommage.
Ce que le vérificateur teste et comment il décide
Le vérificateur découpe votre chemin sur les slashes et ignore la query string et le fragment, car ils ne font pas partie du nommage des ressources. Chaque segment restant est ensuite testé selon quatre règles, et chaque échec est signalé séparément afin que vous voyiez exactement quelle convention un segment enfreint. Premièrement, les minuscules : toute lettre majuscule dans un segment est signalée, car la casse dans les chemins est une source fréquente de bugs de routage sur les serveurs sensibles à la casse.
Deuxièmement, l'usage des tirets : les underscores et les espaces dans un segment sont signalés, avec les tirets comme remplacement recommandé. Troisièmement, les noms au pluriel : les segments qui ne sont ni des préfixes de version ni des paramètres de chemin doivent se terminer par un mot à consonance plurielle ; un segment comme /user est signalé tandis que /users passe, et les segments composés comme /user-profiles sont jugés sur leur dernier mot.
Quatrièmement, les verbes : chaque mot séparé par des tirets est comparé à une liste fixe de verbes anglais courants comme get, create, update, delete, fetch et login, et toute correspondance est signalée. Les paramètres de chemin sous les formes {id} ou :id sont exemptés des règles sur les noms et les verbes, car un nom de paramètre suit des conventions différentes de celles d'un nom de ressource statique.
Cas d’usage
Trancher les débats de style en revue de conception
Remplacez les opinions par une liste concrète de violations lorsque deux relecteurs ne sont pas d'accord sur la forme d'un chemin.
Questions fréquentes
Combien cela coûte-t-il ?
C'est aussi gratuit dans votre navigateur sur cette page.
Comment l'outil décide-t-il si un mot est au pluriel ?
Avec une heuristique simple et déterministe : le dernier mot séparé par des tirets d'un segment doit se terminer par « s ». Les segments de version comme v1 et les paramètres de chemin comme {id} ou :id sont exemptés.
L'outil vérifie-t-il les query strings ou les fragments ?
Non. Tout ce qui suit « ? » ou « # » est supprimé avant les vérifications, car les paramètres de requête et les fragments ne font pas partie du nommage des ressources.
Quelle liste de verbes l'outil utilise-t-il ?
La liste est déterministe et ne change pas entre les appels.
Pourquoi des tirets plutôt que des traits de soulignement ou le camelCase ?
Les traits de soulignement se lisent mal dans une adresse web et peuvent disparaître sous le soulignement d'un lien, tandis que le camelCase mélange des majuscules là où les minuscules sont la norme. Soulignements et espaces sont donc signalés, avec le tiret comme correction.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre 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)Exemple de requête
{
"path": "/api/v1/user-profiles"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rest_endpoint_naming_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
max_chars | 2048 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Le vérificateur de nommage d'endpoints REST prend un chemin tel que /users/{id}/orders et teste chaque segment selon les conventions sur lesquelles la plupart des guides de style s'accordent : les segments doivent être en minuscules, les mots séparés par des tirets plutôt que par des underscores ou du camelCase, les ressources de collection doivent être des noms au pluriel, et les verbes doivent rester hors du chemin car la méthode HTTP nomme déjà l'action.
À quoi ressemble un bon chemin REST
Les chemins REST nomment des ressources, pas des actions. L'action réside déjà dans la méthode HTTP — GET, POST, PUT, DELETE — donc un chemin comme /getUsers dit la même chose deux fois et de manière incohérente avec le reste de l'API. Quand un chemin suit ces règles, il devient prévisible : un développeur qui connaît un endpoint peut deviner le reste de la surface sans lire la documentation, et les outils comme les routeurs, les passerelles et les linters peuvent être configurés une fois et réutilisés pour chaque service livré par l'équipe.
Utiliser le verdict dans les revues et les pipelines
La sortie est conçue pour être exploitable par une machine autant que lisible. Un flux de travail typique consiste à exécuter le vérificateur sur chaque nouvelle route ajoutée par un service : collez le chemin pendant la revue de conception, détectez l'écart avant que la route ne soit livrée, et évitez le choix douloureux ultérieur entre garder un chemin disgracieux pour toujours ou casser les clients avec un renommage. En plus de la liste des problèmes en langage clair, vous obtenez un objet checks avec un booléen par convention — lowercase, hyphenated, plural_nouns et no_verbs — ainsi qu'un drapeau valid global, de sorte qu'une tâche CI peut faire échouer une pull request sur une seule condition au lieu d'analyser des phrases. Les équipes l'utilisent aussi lors d'audits d'API, en y injectant les routes d'un document OpenAPI et en collectant les segments qui demandent de l'attention. Le même code qui alimente l'API s'exécute gratuitement dans votre navigateur sur cette page, ce qui vous permet de tester des chemins de façon interactive pendant la conception et de ne payer les $0.002 par requête que lorsque vous automatisez la vérification dans un pipeline, un linter ou un portail développeur interne.
Cas d'intégration
Verrouiller les nouvelles routes en CI
Faites échouer une pull request lorsqu'un endpoint nouvellement ajouté introduit des verbes, des underscores ou des majuscules dans le chemin.
Auditer une surface d'API existante
Passez les routes d'un document OpenAPI au vérificateur et collectez les segments qui enfreignent votre guide de style.
Questions techniques
Pourquoi les verbes ne sont-ils pas autorisés dans un chemin REST ?
Parce que la méthode HTTP nomme déjà l'action. Un chemin comme /getUsers duplique GET et se désynchronise du reste de l'API ; /users avec la méthode GET dit la même chose de manière cohérente.
Que se passe-t-il si j'envoie un chemin vide ?
La requête échoue avec une erreur invalid_input expliquant qu'un chemin non vide est requis. Une entrée vide n'est jamais facturée.