Prompt y alcance
Una versión de API pública y un recurso web se eliminan permanentemente. El equipo desea que los clientes dejen de reintentar mientras se preserva una ruta de migración y evidencia de auditoría. Compara 410, 404, 301/308 y 403; luego diseña respuestas, almacenamiento en caché, una ventana de apagado y monitoreo.
Esta es una pregunta sobre semántica de HTTP y ciclo de vida del producto. La versión y la fecha de retiro son supuestos, no afirmaciones de mercado.
Qué evalúa el entrevistador
- Si distingues entre "actualmente no disponible" y "se sabe que fue eliminado permanentemente".
- Si comprendes los efectos de 410 en el almacenamiento en caché y en los clientes.
- Si la migración, la autorización, la privacidad y la auditoría comparten un modelo de ciclo de vida.
- Si evitas usar un código de estado para ocultar una interrupción desconocida o un error de enrutamiento.
Preguntas aclaratorias para hacer
- ¿El recurso está eliminado permanentemente, temporalmente fuera de línea o movido a un URI estable?
- ¿Están involucrados cachés, índices de búsqueda, reintentos de SDK o clientes fuera de línea?
- ¿Las reglas de retención, cumplimiento normativo o auditoría restringen la eliminación?
- ¿Pueden los clientes antiguos comprender 410 y la información de migración en el cuerpo del error?
- ¿Deberían los usuarios no autorizados ver un 404 para ocultar la existencia del recurso?
Una respuesta en 30 segundos
"410 significa que el servidor sabe que el objetivo existió pero fue eliminado permanentemente; 404 solo indica que no hay una representación actual disponible. Usa 301 o 308 cuando exista un reemplazo estable, y 403 o un 404 por motivos de seguridad para la autorización. Anuncia el retiro mediante documentación, SDKs y una ventana de migración; luego devuelve un 410 con un código estable y un enlace a la documentación usando controles de caché deliberados. Los clientes deben detener los reintentos inútiles. La eliminación sigue siendo auditable, y mido el tráfico de retiro, el comportamiento de la caché y el éxito de la migración".
Diseño paso a paso
1. Construir una tabla de decisión de estados
Usa 410 para un recurso eliminado permanentemente que no se volverá a servir. Usa 404 cuando se desconozca la existencia o la disponibilidad futura, y una redirección cuando el recurso tenga un nuevo URI claro. Que un fallo de autorización sea un 403 o un 404 encubierto depende del modelo de amenazas y la política de divulgación.
2. Diseñar la respuesta 410
Incluye un código de error estable, ID de solicitud, documentación sobre el retiro y una pista opcional de reemplazo. No expongas motivos de eliminación sensibles ni el estado de la base de datos. Una API puede usar un cuerpo de error estructurado; una página web puede proporcionar una explicación de migración accesible. Ambos deben conservar la semántica 410 legible por máquina.
HTTP/1.1 410 Gone
Cache-Control: max-age=3600
Content-Type: application/problem+json
Link: <https://api.example/migrations/v1>; rel="deprecation"3. Manejar el almacenamiento en caché y los clientes
410 generalmente se puede almacenar en caché de forma heurística, a menos que la definición del método o los controles explícitos de caché indiquen lo contrario. Evalúa el riesgo de revocación falsa, el comportamiento de la CDN y las cachés locales del cliente antes de elegir un tiempo de vida. Si la decisión puede cambiar, comienza con un tiempo corto y extiéndelo gradualmente. Un cliente que observa un 410 debe detener los reintentos inútiles y pasar a la lógica de migración o notificación al usuario.
4. Planificar la ventana de retiro
Publica la fecha de desuso en la documentación, los SDKs y los encabezados de respuesta; luego segmenta el uso por emisor de la llamada, versión y tráfico. Durante la ventana sirve con éxito junto con señales de migración; después devuelve 410. Las escrituras de alto riesgo pueden rechazarse primero mientras permanece un endpoint de migración de solo lectura. Define puntos de control de reversión antes de cada cambio.
5. Preservar evidencia de eliminación y privacidad
410 no prueba la eliminación física del almacenamiento. Registra la identidad del recurso, la aprobación, la hora de eliminación, la política de retención, el punto de entrada de reemplazo y la versión de la respuesta. Nunca retengas contenido sensible eliminado en los registros. Si el cumplimiento exige una eliminación retrasada, expón 410 mientras la retención interna y la limpieza continúan bajo sus propios controles.
6. Monitorear los resultados clasificados
Divide 410 por recurso, cliente, versión de SDK, acierto de caché y clic de migración para distinguir un retiro real de un error de enrutamiento. Compara 404, 403, cadenas de redirecciones, volumen de reintentos y tickets de soporte. Si el 410 aumenta inesperadamente, deja de extender los tiempos de vida de caché y revierte la configuración mientras investigas.
Respuesta modelo de alta calidad
"Primero establezco el estado del recurso. La eliminación permanente confirmada recibe 410; la ausencia desconocida o temporal recibe 404; un reemplazo claro recibe 301 o 308; la autorización utiliza 403 o un 404 por motivos de seguridad. Anuncio una ventana de migración mediante documentación, SDKs y encabezados, y luego devuelvo 410 con un código estable, ID de solicitud y enlace a la documentación usando un almacenamiento en caché prudente. Los clientes detienen los reintentos. La eliminación y la retención se auditan por separado, mientras que las métricas cubren las fuentes de 410, las cachés, el éxito de la migración y los activadores de reversión".
Errores comunes
- Devolver 410 para cada eliminación → los estados temporales o desconocidos parecen permanentes → clasifica el estado del recurso.
- Devolver 410 a pesar de existir un reemplazo → los clientes pierden la migración → usa 301/308 y documentación.
- Almacenar 410 en caché para siempre → un retiro erróneo es difícil de deshacer → establece y extiende el TTL según el riesgo.
- Tratar 410 como prueba de eliminación física → se omiten la retención y el cumplimiento → audita la limpieza por separado.
- Observar solo un total → los fallos de SDKs antiguos permanecen ocultos → segmenta por versión, recurso y caché.
Preguntas de seguimiento y respuestas
¿Cuál es la diferencia esencial entre 410 y 404?
410 indica que el servidor confirma que el recurso existió y fue eliminado permanentemente. 404 no indica si existió ni si podría aparecer más adelante. Elegir 410 ofrece una promesa más fuerte sobre los reintentos, el almacenamiento en caché y el comportamiento de migración.
¿Puede un 410 incluir un enlace de reemplazo?
Sí, puede proporcionar documentación o un punto de entrada de migración, pero no debe pretender que el reemplazo es el recurso actual. El cliente aún debe volver a verificar la autorización, la versión y el mapeo de datos.
¿Por qué un usuario no autorizado podría recibir un 404?
Si revelar que un recurso existe filtra información confidencial, el servidor puede ocultar la existencia con 404 según su modelo de amenazas. Los clientes autorizados aún deben recibir una semántica de ciclo de vida consistente y auditable.