Verifica nomi endpoint REST
Incolli un percorso come /users/{id}/orders e veda quali regole di denominazione rispetta: minuscole, parole separate da trattini, nomi plurali e nessun verbo. Ogni regola violata è indicata per segmento, così un commento di revisione diventa una correzione. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Percorso
- /v1/users/{id}/orders
- Segmenti
- 4
Lei invia un solo percorso e riceve un verdetto strutturato: quali convenzioni sono state rispettate, quali no, e una spiegazione chiara per ogni segmento non conforme, così un commento di revisione diventa una correzione invece di una discussione.
Com'è fatto un percorso ben nominato
La convenzione ampiamente accettata prevede che ogni segmento del percorso sia un sostantivo e che le collezioni usino la forma plurale: /users per la collezione, /users/{id} per un singolo elemento. Le parole all'interno di un segmento vanno separate con i trattini, lo stile kebab-case, perché gli underscore sono più difficili da leggere negli URL e possono sparire sotto la sottolineatura dei link, mentre il camelCase mescola maiuscole e minuscole in un contesto dove la norma è il minuscolo.
I prefissi di versione come v1 o v2 sono una pratica accettata e non vengono trattati come errori di naming.
Cosa verifica questo strumento e come decide
Il verificatore suddivide il percorso sulle barre e ignora la query string e il frammento, perché non fanno parte del naming delle risorse. Ogni segmento restante viene poi sottoposto a quattro regole, e ogni violazione viene segnalata separatamente, così può vedere esattamente quale convenzione un segmento infrange. Primo, il minuscolo: qualsiasi lettera maiuscola in un segmento viene segnalata, poiché le maiuscole nei percorsi sono una causa frequente di bug di routing sui server case-sensitive.
Secondo, la separazione con trattini: underscore e spazi all'interno di un segmento vengono segnalati, indicando i trattini come sostituti. Terzo, i sostantivi plurali: i segmenti che non sono prefissi di versione né parametri di percorso devono terminare con una parola che abbia forma plurale; un segmento come /user viene segnalato mentre /users supera la verifica, e i segmenti composti come /user-profiles vengono giudicati dalla loro ultima parola.
Quarto, i verbi: ogni parola separata da trattini viene confrontata con un elenco fisso di verbi inglesi comuni come get, create, update, delete, fetch e login, e ogni corrispondenza viene segnalata. I parametri di percorso nelle forme {id} o :id sono esenti dalle regole su sostantivi e verbi, perché il nome di un parametro segue convenzioni diverse da quelle di una risorsa statica.
Casi d'uso
Dirimere i dibattiti di stile in fase di revisione
Sostituisca le opinioni con un elenco concreto di violazioni quando due revisori non concordano su come dovrebbe essere un percorso.
Domande frequenti
Quanto costa?
L'esecuzione nel browser su questa pagina è inoltre gratuita.
Come decide se una parola è plurale?
Con un'euristica semplice e deterministica: l'ultima parola di un segmento, separata dai trattini, deve terminare in 's'. I segmenti di versione come v1 e i parametri di percorso come {id} o :id sono esenti.
Verifica le query string o i frammenti?
No. Tutto ciò che segue '?' o '#' viene rimosso prima delle verifiche, poiché i parametri di query e i frammenti non fanno parte del naming delle risorse.
Quale elenco di verbi utilizza?
L'elenco è deterministico e non cambia tra una chiamata e l'altra.
Perché i trattini e non i trattini bassi o il camelCase?
I trattini bassi si leggono male in un indirizzo web e possono sparire sotto la sottolineatura di un link, mentre il camelCase mescola maiuscole dove la norma sono le minuscole. Per questo trattini bassi e spazi vengono segnalati, con il trattino come correzione.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"path": "/api/v1/user-profiles"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rest_endpoint_naming_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Limiti
max_chars | 2048 |
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Il verificatore di naming degli endpoint REST prende un percorso come /users/{id}/orders e ne esamina ogni segmento rispetto alle convenzioni su cui concordano le principali guide di stile: i segmenti devono essere in minuscolo, le parole vanno separate da trattini e non da underscore o camelCase, le collezioni di risorse devono essere sostantivi plurali e i verbi devono restare fuori dal percorso, perché il metodo HTTP indica già l'azione.
Come si presenta un buon percorso REST
I percorsi REST danno un nome alle risorse, non alle azioni. L'azione risiede già nel metodo HTTP — GET, POST, PUT, DELETE — quindi un percorso come /getUsers ripete due volte la stessa cosa e la dice in modo incoerente rispetto al resto dell'API. Quando un percorso segue queste regole diventa prevedibile: uno sviluppatore che conosce un endpoint può intuire il resto della superficie senza leggere la documentazione, e strumenti come router, gateway e linter possono essere configurati una sola volta e riutilizzati in ogni servizio che il team rilascia.
Usare il verdetto nelle revisioni e nelle pipeline
L'output è pensato per essere leggibile dalle macchine oltre che dalle persone. Un flusso di lavoro tipico consiste nell'eseguire il verificatore su ogni nuova rotta aggiunta da un servizio: incolli il percorso durante la revisione della progettazione, individui la deviazione prima del rilascio della rotta ed eviti la scelta dolorosa tra mantenere per sempre un percorso brutto o rompere i client con una ridenominazione. Accanto all'elenco di problemi in linguaggio chiaro ottiene un oggetto checks con un booleano per ogni convenzione — lowercase, hyphenated, plural_nouns e no_verbs — più un flag valid complessivo, così un job CI può bloccare una pull request su una singola condizione invece di analizzare frasi. I team lo usano anche durante gli audit delle API, fornendo le rotte di un documento OpenAPI e raccogliendo i segmenti che richiedono attenzione. Lo stesso codice che alimenta l'API funziona gratuitamente nel suo browser su questa pagina, così può testare i percorsi in modo interattivo durante la progettazione e spendere i $0.002 per richiesta solo quando automatizza la verifica in una pipeline, in un linter o in un portale interno per sviluppatori.
Casi di integrazione
Bloccare le nuove rotte in CI
Blocchi una pull request quando un endpoint appena aggiunto introduce verbi, underscore o lettere maiuscole nel percorso.
Verificare una superficie API esistente
Passi le rotte di un documento OpenAPI attraverso il verificatore e raccolga i segmenti che violano la sua guida di stile.
Domande tecniche
Perché i verbi non sono ammessi in un percorso REST?
Perché il metodo HTTP indica già l'azione. Un percorso come /getUsers duplica GET e va fuori sincrono rispetto al resto dell'API; /users con il metodo GET esprime la stessa cosa in modo coerente.
Cosa succede se invio un percorso vuoto?
La richiesta fallisce con un errore invalid_input che spiega che è richiesto un percorso non vuoto. L'input vuoto non viene mai addebitato.