HTTP 201 Created: qué significa

Qué significa este error y cómo reconocerlo

• Un cliente de API, una aplicación basada en navegador, una herramienta de monitorización o un comprobador informa de 201 Created.
• La respuesta puede incluir un objeto recién creado, metadatos del recurso o un encabezado Location.
• El resultado puede producirse únicamente para una ruta, un método HTTP, una cuenta o un payload de solicitud concretos.
• Un 201 correcto puede ir acompañado de advertencias de la aplicación o detalles de validación en el cuerpo de la respuesta.
• Las comprobaciones de DNS y TLS pueden seguir siendo correctas porque un endpoint que habla HTTP devolvió una respuesta; esas comprobaciones son independientes del estado HTTP.

Causas principales, ordenadas por probabilidad

1. Creación de recursos esperada: La ruta crea intencionadamente un registro, una cuenta, una carga, un trabajo, un pedido u otro recurso y devuelve 201 tras completarse correctamente.
2. Se utilizó un método que crea recursos: El cliente envió una solicitud POST o PUT a un endpoint diseñado para crear un recurso. El método y la ruta determinan si 201 es apropiado.
3. La solicitud se repitió o se envió a la ruta equivocada: Un cliente, una integración o un formulario puede estar apuntando a un endpoint de creación cuando debería actualizar un recurso existente o utilizar otra URL.
4. Cambió el comportamiento de la aplicación o del enrutamiento: Un despliegue, controlador, manejador o regla de ruta puede haber modificado el estado devuelto para una solicitud.
5. Un intermediario generó o modificó la respuesta: Un proxy inverso, una CDN, un WAF o una gateway pueden estar implicados, especialmente cuando los encabezados difieren entre las solicitudes directas y las públicas.
6. La interpretación del cliente es engañosa: Una regla de monitorización puede clasificar cualquier respuesta HTTP que no sea un error como inusual, aunque 201 sea válido para ese endpoint.

Cómo solucionarlo

Primero decide si HTTP 201 es esperado

1. Registra la URL exacta, el método HTTP, el cuerpo de la solicitud o los parámetros relevantes, el contexto de la cuenta y la marca de tiempo. No incluyas contraseñas, cookies, tokens de acceso ni otros secretos en las notas compartidas.
2. Comprueba el comportamiento documentado del endpoint o el contrato de la aplicación. Un endpoint de creación suele devolver 201; una solicitud a una página de solo lectura normalmente no debería crear un recurso.
3. Inspecciona el cuerpo y los encabezados de la respuesta. Busca un encabezado Location, un identificador de recurso, el tipo de contenido, un ID de solicitud, información de caché y cualquier advertencia de la aplicación. Trata los encabezados como indicios, no como una prueba de que un componente concreto generó la respuesta.
4. Confirma si el cliente siguió redirecciones o informó de una respuesta intermedia. Registra la respuesta final por separado de cualquier respuesta anterior.

Si eres usuario de una API o visitante

1. Si la operación debía crear algo, verifica en la aplicación que el nuevo recurso existe antes de volver a enviar la solicitud.
2. Si la operación no debía crear nada, detén los reintentos repetidos y comprueba la ruta, el método HTTP y la configuración del cliente.
3. Si se requiere autenticación, inicia sesión mediante el flujo normal de la aplicación y repite la operación solo cuando sea seguro y estés autorizado para hacerlo.
4. Proporciona al propietario del sitio la URL y el método depurados, la marca de tiempo, los encabezados de respuesta relevantes y el ID de solicitud, si está disponible. No compartas nunca credenciales, cookies de sesión ni secretos de API.

Si eres propietario de la aplicación o del sitio

1. Reproduce la solicitud en un entorno seguro o con una cuenta de prueba autorizada. Captura el método, la URL, el estado, los encabezados de respuesta y un cuerpo de respuesta con los datos confidenciales ocultos.
2. Identifica el componente que produjo la respuesta: el manejador de la aplicación, el servidor web, el proxy inverso, la CDN, el WAF u otra gateway. Compara los ID de solicitud o los encabezados de tiempo generados por el servidor con los registros cuando estén disponibles.
3. Inspecciona los registros correspondientes de la aplicación y de la infraestructura en la marca de tiempo registrada. Confirma si realmente se creó un recurso y si la operación se confirmó una vez o más de una vez.
4. Revisa los cambios recientes en las rutas, los controladores, el procesamiento de solicitudes, la autenticación, las reglas del proxy y los despliegues. Presta especial atención a los clientes que puedan reintentar solicitudes de creación no idempotentes.
5. Si 201 es incorrecto para el endpoint, cambia la regla de aplicación o de enrutamiento más específica que controle la respuesta. Obtén autorización y prueba el cambio antes de aplicarlo en producción.
6. Vuelve a probar con el mismo método, URL y payload; después, prueba las rutas relacionadas de creación, lectura y actualización para asegurarte de que sus códigos de estado previstos y el comportamiento de los recursos siguen siendo correctos.

Prevención y cómo verificar la solución

• Define los métodos HTTP y códigos de estado esperados para cada ruta pública, incluido el comportamiento de creación y de solicitudes duplicadas.
• Prueba las operaciones de creación, lectura y actualización con casos representativos autenticados y no autenticados después de los despliegues.
• Haz que los clientes gestionen 201 explícitamente y verifiquen el recurso devuelto o el encabezado Location antes de reintentar.
• Utiliza identificadores de solicitud y conserva los registros de la aplicación, el proxy y la gateway durante el tiempo suficiente para rastrear una respuesta inesperada.
• Supervisa las tasas de códigos de estado por ruta y método en lugar de tratar todas las respuestas 2xx como intercambiables.
• Mantén bajo control de versiones los cambios de enrutamiento, autenticación, proxy y aplicación, y documenta las respuestas 201 intencionadas.

Preguntas frecuentes