Entrevista de backend: ¿Cuándo debería HTTP 226 IM Used transportar un delta?

Prompt y alcance

Una API devuelve un documento JSON grande y el cliente almacena el ETag anterior. Explique cuándo es apropiado HTTP 226 IM Used, qué encabezados intercambian el cliente y el servidor, y cómo se preserva la corrección cuando no se puede aplicar un delta. Cubra la negociación, el almacenamiento en caché y el fallback; no se requiere un algoritmo de diff específico.

Qué está evaluando el entrevistador

• Si sabe que 226 representa un delta para GET, no un éxito incompleto arbitrario.
• Si puede conectar A-IM, IM, ETag y el opcional Delta-Base en un solo intercambio.
• Si identifica los límites de versión base, concurrencia de caché, costo del algoritmo y 200 completo.
• Si verificará el soporte en clientes, intermediarios y cachés antes del despliegue.

Preguntas clarificadoras

1. ¿Puede el cliente aplicar un algoritmo negociado de manipulación de instancias?
2. ¿Está el documento fuertemente identificado por un ETag estable y la generación del delta justifica su costo de CPU?
3. ¿Reescribirá o almacenará en caché la respuesta un proxy, y puede este preservar la semántica del delta?
4. ¿Puede el cliente obtener de forma transparente una representación completa cuando su base está desactualizada o es inválida?

Una respuesta de 30 segundos

Haría que 226 fuera una optimización negociada opcional. El cliente envía A-IM y el If-None-Match de la representación base. El servidor devuelve 226 solo cuando soporta un algoritmo y tiene esa base exacta, declarando el algoritmo en IM, un nuevo ETag y Delta-Base cuando sea útil. El cliente verifica la etiqueta base, aplica el delta y valida la etiqueta de entidad resultante. Una discrepancia, una mala relación costo-beneficio, un cliente no soportado o una fusión fallida recurre a un 200 completo. Las cachés solo deben reutilizar un delta cuando su base y los metadatos de respuesta coincidan.

Diseño paso a paso

1. Negociar la capacidad de delta

A-IM lista los algoritmos de manipulación de instancias aceptados por el cliente; el servidor nombra su elección en IM. Esto difiere de la compresión de content-encoding: la compresión cambia la codificación de transferencia, mientras que un delta cambia cómo se produce la representación. Sin un algoritmo soportado mutuamente, use 200.

2. Vincular la base a una versión

El cliente utiliza If-None-Match para identificar su etiqueta de entidad local. El servidor debe confirmar que esa etiqueta se asigna a la representación base, en lugar de adivinar a partir de una marca de tiempo o una versión proporcionada por el cliente. La respuesta lleva un nuevo ETag; Delta-Base puede identificar explícitamente la etiqueta base. El cliente valida el resultado fusionado contra la nueva etiqueta.

3. Hacer que el fallback sea seguro

Si falta la base, el delta es más grande que el documento completo, el algoritmo se agota por tiempo de espera, la fusión falla en la validación o un intermediario no es seguro, devuelva 200. El cliente debe descartar la base inutilizable y resincronizarse, de modo que un delta defectuoso no pueda contaminar actualizaciones posteriores. Aplique presupuestos de tamaño, CPU y tiempo.

4. Tratar las claves de caché y las métricas como parte del protocolo

Las claves de caché deben incluir la URL, los encabezados de negociación y las condiciones que seleccionan la base; un delta válido para un ETag no es una respuesta genérica. Mida la tasa de aciertos de 226, los bytes de delta frente a los completos, los fallos de fusión, la proporción de fallback y la latencia de generación para demostrar que la optimización justifica su complejidad.

Respuesta modelo de alta calidad

Lo implementaría como una optimización con un fallback explícito. El cliente anuncia los algoritmos soportados en A-IM y envía If-None-Match para su base. El servidor verifica que la base exista y que el algoritmo esté en la lista de permitidos, luego compara el tamaño del delta y el costo de generación. Solo entonces devuelve 226, declara el algoritmo con IM, emite el nuevo ETag del resultado y opcionalmente identifica la base con Delta-Base. El cliente verifica la etiqueta base, aplica el delta y valida la nueva etiqueta de entidad antes de reemplazar su documento. Cualquier discrepancia de versión, delta sobredimensionado, falla de fusión o ruta no soportada devuelve 200. Las cachés varían según la negociación y las condiciones base, mientras que la telemetría registra los bytes ahorrados, la CPU, las fallas y el fallback. El soporte de delta mejora la eficiencia de transferencia sin convertirse en un prerrequisito de corrección.

Errores comunes

• Tratar 226 como 206, aun cuando 206 responde a una solicitud Range.
• Enviar solo un número de versión informal en lugar de vincular la base exacta con ETag.
• Asumir que todos los navegadores, proxies y cachés entienden la semántica de delta.
• Omitir la comparación entre el tamaño del delta y el tamaño del documento completo.
• Continuar desde una base inválida tras un fallo de fusión en lugar de resincronizarse.
• Tratar la compresión, JSON Patch y la manipulación de instancias de RFC 3229 como la misma capa de protocolo.

Preguntas de seguimiento y respuestas

¿En qué se diferencia 226 de 206 y 304?

206 devuelve rangos de bytes solicitados con Range; 304 indica que una solicitud condicional no necesita una nueva representación; 226 devuelve un delta basado en una representación existente. Sus condiciones de solicitud, procesamiento del cliente y semántica de caché difieren.

¿Qué pasa si el ETag base está desactualizado?

No aplique el delta a ciegas. Devuelva un 200 completo o haga que el cliente obtenga la base actual, descarte la base local inutilizable y reconstruya su caché a partir de una representación completa.

¿Cómo se previene el envenenamiento de caché de deltas?

Vincule la URL, el algoritmo negociado, el ETag base y el ETag de respuesta; valide IM y Delta-Base; evite que los intermediarios reutilicen un delta para otra base; y verifique la integridad de la entidad fusionada.