Sugerir método HTTP para acción CRUD
Escriba create y obtenga el método convencional con 201 Created, una pista de la ruta y una nota sobre la convención; update devuelve PUT para un reemplazo completo y menciona PATCH para cambios parciales. La misma acción da siempre la misma respuesta. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Acción
- create
- Estado
- 201
- Texto de estado
- Created
- Sugerencia de ruta
- POST /resources
Es una correspondencia determinista, no una suposición: la misma acción produce siempre la misma respuesta, sin ningún modelo de por medio. Las acciones no reconocidas se rechazan con un error claro que enumera los valores aceptados, de modo que un error tipográfico en la automatización falla ruidosamente en lugar de generar en silencio una ruta incorrecta.
Por qué PUT para actualizar y dónde encaja PATCH
La celda más debatida de la tabla es la de update. PATCH existe para el otro caso común, en el que el cliente solo envía los campos que cambiaron y el servidor los fusiona; la nota devuelta lo indica explícitamente, de modo que quien revisa ve la alternativa en lugar de tratar la correspondencia como un dogma. En la práctica, muchas APIs en producción usan PATCH para actualizaciones parciales y reservan PUT para el reemplazo completo, y algunas prescinden de PUT por completo.
Lo importante en un diseño es elegir una convención y aplicarla de manera uniforme en todos los recursos, que es precisamente el tipo de decisión que una consulta determinista ayuda a hacer cumplir cuando se integra en herramientas de generación de código y listas de verificación de revisiones.
Los códigos de estado son la mitad de la respuesta
Un create que responde 200 OK en lugar de 201 Created no está roto, pero desperdicia una señal que la especificación ofrece gratis, y los clientes automatizados que deciden según el estado lo interpretarán mal. Un delete que responde 200 con un cuerpo vacío obliga al cliente a analizar nada donde 204 No Content lo habría dicho todo en la línea de estado.
La correspondencia devuelta aquí empareja cada acción con el estado que debe producir una llamada exitosa — 201 para create, 200 para read, update y list, 204 para delete — junto con la frase descriptiva estándar, de modo que la documentación generada y las secciones de respuestas de OpenAPI salgan correctas por construcción.
Los errores quedan deliberadamente fuera del alcance: la capacidad responde únicamente la convención del caso favorable y rechaza los nombres de acción no reconocidos con un mensaje claro que enumera los cinco valores aceptados en lugar de adivinar una coincidencia aproximada.
Preguntas frecuentes
¿Cuánto cuesta?
La misma correspondencia también funciona gratis en su navegador en esta página.
¿Qué acciones se aceptan?
create, read, update, delete y list. La comparación no distingue mayúsculas de minúsculas y se ignoran los espacios alrededor; cualquier otro valor se rechaza con un error que enumera los valores aceptados.
¿Por qué PUT y no PATCH para update?
PUT es el reemplazo completo idempotente convencional, que es lo que devuelve la correspondencia. La nota de la respuesta señala PATCH como la opción estándar para actualizaciones parciales, para que usted elija deliberadamente.
¿La respuesta es alguna vez aleatoria o generada por un modelo?
No. La correspondencia es una tabla determinista fija; la misma acción siempre devuelve el mismo método, estado y nota.
¿Una acción de crear debe responder 200 o 201?
201 Created, normalmente con una cabecera Location que apunta al recurso nuevo. Un 200 OK no es un error, pero desperdicia una señal que la especificación ya ofrece, y los clientes que deciden según el estado lo interpretarán mal.
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/http-method-from-action-suggest \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"create"}'const res = await fetch("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"action": "create"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/http-method-from-action-suggest",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"action": "create"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"action":"create"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"action":"create"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/http-method-from-action-suggest", 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
{
"action": "create"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"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.
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 endpoint de método HTTP para acciones CRUD responde a la pregunta que todo diseñador de APIs se hace una docena de veces al día: dada una acción como create, read, update, delete o list, ¿qué método HTTP debe usar el endpoint y qué código de estado debe devolver una llamada exitosa? Usted envía un solo nombre de acción y recibe el verbo REST convencional, el estado de éxito típico con su frase descriptiva, una sugerencia de ruta que muestra cómo se escribe habitualmente el path y una breve nota que explica la convención. Úselo al generar rutas, revisar un diseño de API, crear esqueletos de OpenAPI o enseñar convenciones REST a un equipo que sigue confundiendo PUT y PATCH.
La correspondencia convencional, en una tabla
REST asigna las cuatro operaciones de persistencia a verbos HTTP, más la lectura de colección que toda API real también necesita. Create corresponde a POST sobre la colección y convencionalmente responde 201 Created, a menudo con una cabecera Location que apunta al nuevo recurso. Read corresponde a GET sobre un recurso individual y responde 200 OK; es seguro e idempotente, razón por la cual las cachés y los reintentos pueden ser agresivos con él. Update corresponde a PUT cuando el cliente reemplaza el recurso por completo, respondiendo 200 OK con la representación actualizada; ese mismo endpoint es idempotente, así que una petición reintentada no causa daño adicional. Delete corresponde a DELETE y normalmente responde 204 No Content, pues ya no queda nada que describir. List corresponde a GET sobre la colección, responde 200 OK y es donde viven los parámetros de paginación, filtrado y ordenación. Este endpoint devuelve exactamente esa fila de la tabla, con el razonamiento adjunto, de modo que la respuesta pueda pegarse en un documento de diseño o verificarse en una prueba sin releer una guía de estilo.
Por qué PUT para actualizar y dónde encaja PATCH
Esta capacidad sigue la lectura más estricta de la especificación HTTP: PUT reemplaza el recurso completo con la representación que envía el cliente, lo que lo hace idempotente: enviar el mismo PUT dos veces deja el servidor exactamente en el mismo estado. Esa propiedad es la que convierte a PUT en la opción convencional por defecto para un endpoint de actualización y en la respuesta que esta API da para la acción update.
Los códigos de estado son la mitad de la respuesta
Elegir el verbo es solo la mitad del diseño de un endpoint; el código de estado de éxito es la otra mitad, y equivocarse confunde a los clientes.
Casos de integración
Generar rutas REST
Genere esqueletos de rutas para un nuevo recurso con el verbo y el estado convencionales ya completados para cada acción CRUD.
Revisar un diseño de API
Compare una lista de endpoints propuesta con la correspondencia convencional y señale las rutas que se desvían antes de publicarlas.
Enseñar convenciones REST
Ofrezca a su equipo una referencia determinista única para la cuestión del verbo y el estado en lugar de volver a discutirla en cada revisión.
Preguntas técnicas
¿Cubre los códigos de estado de error?
No. Responde únicamente el caso de éxito convencional: el método HTTP, el código de estado de éxito típico y una breve explicación de la convención.
¿Qué ocurre con una acción no reconocida?
La solicitud falla con un error invalid_input cuyo mensaje indica el valor recibido y enumera las cinco acciones aceptadas.