Verificador de nombres de endpoints REST
Pegue una ruta como /users/{id}/orders y vea qué reglas de nombres cumple: minúsculas, palabras separadas por guiones, sustantivos en plural y ningún verbo. Cada regla incumplida se indica por segmento, así un comentario de revisión se convierte en una corrección. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Ruta
- /v1/users/{id}/orders
- Segmentos
- 4
Usted envía una ruta y recibe un veredicto estructurado: qué convenciones se cumplieron, cuáles fallaron y un problema legible para cada segmento infractor, de modo que un comentario de revisión se convierte en una corrección y no en un debate.
Cómo es una ruta bien nombrada
La convención ampliamente aceptada es que cada segmento de la ruta sea un sustantivo y que las colecciones usen la forma plural: /users para la colección, /users/{id} para un miembro de ella. Las palabras dentro de un segmento se separan con guiones, el estilo kebab-case, porque los guiones bajos son más difíciles de leer en las URL y pueden desaparecer bajo el subrayado de los enlaces, mientras que camelCase mezcla mayúsculas en un lugar donde la norma es la minúscula.
Los prefijos de versión como v1 o v2 son práctica aceptada y no se tratan como errores de nomenclatura.
Qué evalúa este verificador y cómo decide
El verificador divide su ruta por las barras e ignora la query string y el fragmento, porque no forman parte de la nomenclatura del recurso. Cada segmento restante se evalúa frente a cuatro reglas, y cada fallo se reporta por separado para que usted vea exactamente qué convención infringe un segmento. Primero, minúsculas: se señala cualquier letra mayúscula en un segmento, ya que las mayúsculas en las rutas son una fuente común de errores de enrutamiento en servidores sensibles a mayúsculas.
Segundo, guiones: se señalan los guiones bajos y los espacios dentro de un segmento, indicando el guion como reemplazo. Tercero, sustantivos en plural: los segmentos que no son prefijos de versión ni parámetros de ruta deben terminar en una palabra con apariencia plural; un segmento como /user se señala mientras que /users pasa, y los segmentos compuestos como /user-profiles se juzgan por su última palabra.
Cuarto, verbos: cada palabra separada por guiones se compara con una lista fija de verbos comunes en inglés como get, create, update, delete, fetch y login, y se señala cualquier coincidencia. Los parámetros de ruta con las formas {id} o :id están exentos de las reglas de sustantivos y verbos, porque el nombre de un parámetro sigue convenciones distintas a las de un nombre de recurso estático.
Qué puede hacer con ella
Resolver debates de estilo en la revisión de diseño
Sustituya la opinión por una lista concreta de infracciones cuando dos revisores discrepen sobre cómo debe leerse una ruta.
Preguntas frecuentes
¿Cuánto cuesta?
También es gratis ejecutarlo en su navegador en esta página.
¿Cómo decide si una palabra está en plural?
Con una heurística simple y determinista: la última palabra separada por guiones de un segmento debe terminar en 's'. Los segmentos de versión como v1 y los parámetros de ruta como {id} o :id están exentos.
¿Verifica query strings o fragmentos?
No. Todo lo que esté después de '?' o '#' se elimina antes de las verificaciones, ya que los parámetros de consulta y los fragmentos no forman parte de la nomenclatura del recurso.
¿Qué lista de verbos utiliza?
La lista es determinista y no cambia entre llamadas.
¿Por qué guiones y no guiones bajos ni camelCase?
Los guiones bajos se leen peor en una dirección web y pueden desaparecer bajo el subrayado de un enlace, y el camelCase mete mayúsculas donde lo normal son minúsculas. Por eso se marcan los guiones bajos y los espacios, y se propone el guion.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"path": "/api/v1/user-profiles"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rest_endpoint_naming_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_chars | 2048 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
El verificador de nomenclatura de endpoints REST toma una ruta como /users/{id}/orders y evalúa cada segmento frente a las convenciones en las que coinciden la mayoría de las guías de estilo: los segmentos deben estar en minúsculas, las palabras deben separarse con guiones en lugar de guiones bajos o camelCase, las colecciones deben ser sustantivos en plural y los verbos deben quedar fuera de la ruta, porque el método HTTP ya nombra la acción.
Cómo es una buena ruta REST
Las rutas REST nombran recursos, no acciones. La acción ya reside en el método HTTP — GET, POST, PUT, DELETE —, así que una ruta como /getUsers dice lo mismo dos veces y lo dice de forma incoherente con el resto de la API. Cuando una ruta sigue estas reglas se vuelve predecible: un desarrollador que conoce un endpoint puede adivinar el resto de la superficie sin leer la documentación, y herramientas como routers, gateways y linters pueden configurarse una vez y reutilizarse en todos los servicios que el equipo publique.
Uso del veredicto en revisiones y pipelines
La salida está diseñada para ser consumible por máquinas además de legible. Un flujo típico consiste en ejecutar el verificador sobre cada nueva ruta que agrega un servicio: pegue la ruta durante la revisión de diseño, detecte la desviación antes de publicarla y evite la dolorosa elección posterior entre mantener una ruta fea para siempre o romper clientes con un renombrado. Junto a la lista de problemas en lenguaje sencillo, usted recibe un objeto checks con un booleano por convención — lowercase, hyphenated, plural_nouns y no_verbs — más una bandera global valid, de modo que un trabajo de CI puede rechazar un pull request con una sola condición en lugar de analizar frases. Los equipos también lo usan en auditorías de API, alimentándolo con rutas de un documento OpenAPI y recopilando los segmentos que necesitan atención. El mismo código que impulsa la API se ejecuta gratis en su navegador en esta página, así que usted puede probar rutas de forma interactiva mientras diseña y solo gastar los $0.002 por solicitud cuando automatice la verificación dentro de un pipeline, un linter o un portal interno para desarrolladores.
Casos de integración
Bloquear rutas nuevas en CI
Rechace un pull request cuando un endpoint recién agregado introduzca verbos, guiones bajos o mayúsculas en la ruta.
Auditar la superficie de una API existente
Pase las rutas de un documento OpenAPI por el verificador y recopile los segmentos que infringen su guía de estilo.
Preguntas técnicas
¿Por qué no se permiten verbos en una ruta REST?
Porque el método HTTP ya nombra la acción. Una ruta como /getUsers duplica GET y se desincroniza del resto de la API; /users con el método GET dice lo mismo de forma coherente.
¿Qué ocurre si envío una ruta vacía?
La solicitud falla con un error invalid_input que explica que se requiere una ruta no vacía. La entrada vacía nunca se cobra.