Planteamiento y alcance
Un cliente heredado envía declaraciones de extensión HTTP, y algunas solicitudes requieren que el servidor comprenda la extensión. Una pasarela puede reenviar la solicitud mientras que el origen no la admite. Explique 510 Not Extended, compárelo con 501 y 400, y proponga pasos de compatibilidad, observabilidad, migración y reversión.
RFC 2774 clasifica este marco de extensión como Histórico (Historic). Esta pregunta evalúa la semántica del protocolo; no implica que las API públicas modernas utilicen comúnmente el código 510.
Qué está evaluando el entrevistador
- Si sabe que 510 se refiere a un requisito de extensión HTTP no satisfecho, no a una validación de negocio ordinaria.
- Si puede distinguir un origen que no puede satisfacer una extensión (510) de un método no admitido (501).
- Si reconoce el estado histórico de RFC 2774 en lugar de tratar 510 como un formato de error universal.
- Si su diseño cubre de manera conjunta proxies, cachés, compatibilidad y evidencia de migración.
Preguntas de clarificación
- ¿La solicitud realmente declara una extensión RFC 2774 obligatoria, o solo un encabezado de negocio desconocido?
- ¿Qué salto (cliente, proxy, pasarela u origen) puede interpretar la declaración de la extensión?
- ¿Pueden los clientes actualizarse y existe un formato de solicitud alternativo estable?
- ¿Podría una caja intermedia (middlebox) reescribir, almacenar en caché o envolver la respuesta 510?
- ¿Debe la migración admitir operaciones tanto de lectura como de escritura?
Una respuesta de 30 segundos
“510 es la respuesta de RFC 2774 para una extensión HTTP obligatoria que el servidor no puede satisfacer. 501 significa que el servidor no admite el método solicitado, mientras que 400 significa que la solicitud no es válida en su sintaxis o semántica general. Debido a que RFC 2774 es Histórico, primero demostraría que el tráfico utiliza este marco y luego mantendría 510 como una señal de compatibilidad heredada: devolver un error diagnosticable pero no sensible, registrar el identificador de la extensión y la ruta, y trasladar a los clientes a un contrato de API versionado. Un encabezado de negocio desconocido o un fallo de validación ordinario no deberían convertirse en 510”.
Diseño paso a paso
1. Verificar la declaración de extensión
El escenario de RFC 2774 es más específico que ver un encabezado desconocido. El cliente declara una extensión y su identificador, y puede exigir que el destinatario la entienda. Confirme la declaración en la solicitud sin procesar, en los registros de reenvío del proxy y en los registros del origen antes de decidir si 510 aplica.
2. Separar los códigos de estado vecinos
510 significa que la extensión solicitada no se puede satisfacer; 501 significa que el servidor no implementa el método necesario para procesar la solicitud; 400 significa que la solicitud no se puede analizar o procesar bajo la semántica general. La autenticación, la autorización, la limitación de tasa (throttling) y las reglas de negocio merecen sus propios códigos de estado y códigos de error estables.
3. Diseñar una respuesta diagnosticable
Devuelva un tipo de error estable, el ID de solicitud, un resumen seguro del identificador de la extensión y documentación de migración. No devuelva URIs sin validar, nombres de componentes internos ni datos confidenciales de la solicitud. Si el formato de error común es application/problem+json, deje que 510 identifique la causa del protocolo y coloque los detalles de negocio en los miembros de la extensión.
HTTP/1.1 510 Not Extended
Content-Type: application/problem+json
Cache-Control: no-store
{"type":"https://api.example/problems/unsupported-extension","title":"Required extension is unsupported","status":510,"instance":"req-7f2"}4. Manejar proxies y almacenamiento en caché
Pruebe si un proxy elimina la declaración de extensión, reescribe 510 a 400 o reutiliza el error en una capa de caché. Utilice un almacenamiento en caché conservador para las respuestas que dependen de la identidad, las capacidades o la información del inquilino (tenant). Registre la ruta, el identificador de extensión, la versión del proxy y el resultado del origen sin almacenar solicitudes confidenciales completas.
5. Planificar la migración de sistemas heredados
Mida los fallos por versión de cliente e identificador de extensión. Proporcione un formato de solicitud versionado que no dependa de la extensión y publique una fecha de cambio en la documentación y los SDKs. Durante la ventana de transición, acepte formatos antiguos y nuevos con negociación explícita de capacidades y condiciones de reversión. Retire la ruta antigua solo después de alcanzar un umbral de cobertura de actualización.
6. Definir verificación y reversión
Utilice la cadena de proxies real y pruebas de contrato para cuatro rutas: extensión admitida, extensión faltante, extensión eliminada por una caja intermedia y un encabezado ordinario desconocido. Monitoree las proporciones de 510, 501 y 400 junto con las actualizaciones de los clientes. Si 510 se dispara tras un lanzamiento de configuración, restaure primero la ruta de compatibilidad y luego corrija el análisis; reintentar solo el origen no puede añadir soporte para una extensión ausente.
Respuesta modelo de alta calidad
“Comenzaría con capturas de paquetes y registros de proxy para demostrar que existe una declaración obligatoria de extensión RFC 2774. Solo un origen que no pueda satisfacer esa extensión debería emitir 510; un método no admitido es 501 y una solicitud generalmente no válida es 400. Debido a que RFC 2774 es Histórico, limitaría 510 a la compatibilidad heredada, devolvería un tipo de error estable, el ID de solicitud y la documentación de migración, usaría un almacenamiento en caché conservador y registraría las versiones de la extensión, del proxy y del cliente. Luego ofrecería una API versionada sin extensiones, verificaría el reenvío y las reescrituras con pruebas de contrato, retiraría la ruta antigua según la cobertura de actualización y mantendría un interruptor de reversión”.
Errores comunes
- Devolver 510 ante cualquier encabezado desconocido → no se demostró ninguna extensión obligatoria → analice primero la declaración de extensión y su requisito.
- Tratar 510 como 501 → el fallo de extensión y la ausencia de método son diferentes → aplique el escenario del RFC y la semántica del método por separado.
- Hacer de 510 una convención a largo plazo en una API pública → la compatibilidad del ecosistema se vuelve frágil → marque la dependencia Histórica y migre por versión.
- Permitir el almacenamiento en caché compartido del error → el resultado de capacidad de un cliente afecta a otros → establezca la política de caché según la identidad y los datos de negociación.
- Reintentar únicamente la solicitud antigua → los reintentos no pueden crear soporte para extensiones no implementadas → actualice, degrade o use un formato alternativo.
Preguntas de seguimiento y respuestas
¿Cuál es la diferencia en una sola frase entre 510 y 501?
510 se refiere a una extensión HTTP declarada por la solicitud que no se puede satisfacer; 501 se refiere a un servidor que no admite el método solicitado o la implementación necesaria para él. Ninguno de los dos reemplaza a un código de error de negocio ordinario.
¿Debería un encabezado de negocio desconocido producir un 510?
No directamente. Un encabezado desconocido puede ignorarse, rechazarse según el contrato de negocio o manejarse como un 400; 510 tiene base semántica solo cuando la solicitud exige explícitamente una extensión de estilo RFC 2774 que el servidor no puede satisfacer.
¿Por qué importa el estado Histórico (Historic) de RFC 2774?
Señala ecosistemas de clientes e implementaciones limitados y, por lo tanto, un mayor riesgo de interoperabilidad. Una respuesta sólida de entrevista trata a 510 como un límite de protocolo heredado y controla ese riesgo mediante observación, pruebas de contrato y migración versionada, en lugar de asumir que cada pila HTTP moderna admite dicho marco.