Planteamiento y contexto
El equipo quiere plantillas de URI para la documentación de API, enlaces de paginación y URLs de consultas por lotes como /users{?status,limit}. Las plantillas provienen de la configuración, mientras que algunos valores de variables provienen de los usuarios. Explica los niveles de expresión de RFC 6570, la expansión de caracteres reservados y de listas, y los límites de seguridad para analizar, expandir y validar el resultado.
Qué evalúa el entrevistador
- Separar la sintaxis de la plantilla, la codificación de variables y el análisis y validación del URI final.
- Explicar la diferencia entre expansión simple, reservada, de ruta, de parámetros de matriz y de consulta.
- Manejar listas, mapas asociativos, explode, truncamiento de prefijo y variables no definidas.
- Reconocer riesgos de SSRF, path traversal, redireccionamientos abiertos y fuga de datos derivados de plantillas no confiables.
Preguntas para aclarar primero
- ¿Las plantillas son código estático, configuración revisada o provistas por el tenant/usuario?
- ¿Los resultados solo se muestran, o se envían directamente mediante un cliente HTTP del lado del servidor?
- ¿Las variables son cadenas, listas, mapas asociativos o JSON anidado?
- ¿Qué esquemas, hosts, puertos y prefijos de ruta están permitidos? ¿Debe el resultado permanecer en el origen actual de la API?
- ¿La implementación debe admitir todos los niveles de RFC 6570 o solo un subconjunto aprobado de operadores?
Estructura de respuesta de 30 segundos
Separaría el análisis de la plantilla, la codificación de variables y la política del URI final. Primero definiría los operadores y tipos de valores admitidos de RFC 6570, luego aplicaría la codificación porcentual (percent-encoding) y la expansión de listas y mapas asociativos según el operador; las variables no definidas deben omitirse según la especificación. Trataría cada valor expandido como un URI no confiable, analizaría y validaría su esquema, host, puerto y ruta normalizada, y nunca permitiría que una plantilla elija un destino de red arbitrario del lado del servidor. Las pruebas cubrirían caracteres reservados, Unicode, valores vacíos, claves repetidas, prefijos y rutas hostiles.
Respuesta detallada paso a paso
Paso 1: Definir el límite de la plantilla de URI
Una plantilla de URI es una sintaxis para expresar una referencia de URI con variables. No es un cliente HTTP, una lista de permitidos de URLs ni un enrutador de negocio. La implementación debe analizar literales y expresiones antes de producir un resultado a partir de los valores; no debe concatenar la plantilla en una solicitud ni tratar el valor expandido como una URL ya segura.
Paso 2: Implementar operadores por nivel
RFC 6570 comienza con la expansión de variables simple y agrega formas con caracteres reservados, fragmentos, etiquetas, segmentos de ruta, parámetros de matriz, consultas y continuación de consultas. Los operadores comunes incluyen +, #, ., /, ;, ? y &. Los operadores definen separadores, el comportamiento de valores vacíos y qué caracteres reservados pueden permanecer; una sola regla genérica de reemplazo de cadenas es insuficiente.
Paso 3: Manejar la codificación y los valores compuestos
Los caracteres reservados en una cadena simple se codifican porcentualmente de acuerdo con la expresión. Una lista se puede unir por comas o explotar (explode) en parámetros repetidos; los mapas asociativos tienen sus propios separadores de clave/valor. Un modificador de prefijo toma un prefijo de cadena y no debe confundirse con un recuento de caracteres Unicode, recuento de bytes o truncamiento seguro. Especifica el comportamiento para UTF-8, cadenas vacías y variables no definidas.
Paso 4: Aislar las fuentes de plantillas y variables
Las plantillas estáticas y revisadas en el código pueden admitir más operadores; la configuración de los tenants debe restringir las expresiones, los nombres de variables y los componentes de salida. Los valores pueden provenir de una solicitud, pero una plantilla no debe llamar a funciones, leer variables de entorno ni componer un esquema arbitrario. Mantén el AST de la plantilla separado del mapa de valores para que el nombre de una variable no pueda inyectar nueva sintaxis de expresión.
Paso 5: Validar el URI final
Después de la expansión, usa un analizador de URI estándar para el esquema, la autoridad, la ruta, la consulta y el fragmento. Para solicitudes del lado del servidor, el esquema, el host y el puerto deben coincidir con una lista de permitidos; la resolución DNS también debe bloquear direcciones de loopback, link-local y privadas, y los redireccionamientos deben verificarse nuevamente. Normaliza la ruta antes de verificar su raíz permitida para que un .. codificado no pueda eludir la regla.
Paso 6: Hacer que los enlaces de la API sean mantenibles
Las plantillas de paginación deben especificar qué variables son generadas por el servidor, mientras que los filtros usan nombres y tipos de variables fijos. No coloques firmas, tokens de acceso ni nombres de host internos en plantillas públicas o resultados. Registra versiones de plantillas, esquemas de variables y errores de expansión. Si se requiere un ordenamiento estable, la capa de negocio debe proporcionarlo en lugar de depender del orden de la cadena de parámetros.
Paso 7: Crear pruebas y monitoreo
Prueba cada operador con valores individuales, listas, mapas, valores vacíos y valores no definidos frente a los ejemplos de la especificación. Agrega caracteres reservados, Unicode, claves de consulta repetidas, prefijos largos, codificación doble, %2e%2e, esquemas alternativos, redireccionamientos y casos de resolución DNS. Monitorea fallas de expansión, motivos de rechazo, distribución de orígenes de destino y longitudes anormales, y activa una revisión cuando cambie la configuración de la plantilla.
Respuesta de muestra de alta calidad
Primero restringiría los operadores admitidos de RFC 6570 y separaría el AST de la plantilla, el esquema de variables, la codificación porcentual y la validación del URI final. Las listas, mapas, explode y prefijos siguen sus reglas individuales, y las variables no definidas se omiten; los valores no se pueden volver a analizar como expresiones. Cada resultado sigue siendo un URI no confiable: analízalo, permite solo el esquema, host, puerto y ruta normalizada de la API, bloquea direcciones privadas para solicitudes del lado del servidor y vuelve a verificar cada redireccionamiento. Las pruebas cubren ejemplos de RFC, Unicode, valores vacíos, claves repetidas, doble codificación, traversal y SSRF, registrando las versiones de las plantillas y los motivos de rechazo.
Errores comunes
- Reemplazar la semántica de los operadores con concatenación de cadenas y romper los separadores o la codificación porcentual.
- Tratar la expansión reservada
+como "sin codificación alguna" e ignorar los límites de los componentes. - Tratar listas, mapas y explode como un único formato de unión por comas.
- Validar únicamente el texto de la plantilla en lugar del esquema, host, puerto y ruta normalizada expandidos.
- Tratar la codificación de URL como protección contra SSRF y seguir redireccionamientos sin volver a validarlos.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué debería suceder con una variable no definida?
Omite la variable no definida y el separador necesario según la expresión. No representes la cadena null. Si el esquema de negocio requiere la variable, recházala antes de la expansión.
Pregunta de seguimiento 2: ¿Por qué no llamar a una sola función URL-encode?
La codificación depende de la expresión y del componente del URI. Los parámetros de consulta, los segmentos de ruta y la expansión reservada tienen diferentes separadores y reglas. Una sola función no puede decidir sobre valores compuestos, valores vacíos, prefijos y operadores.
Pregunta de seguimiento 3: ¿Cómo se reduce el riesgo para las plantillas de los tenants?
Usa un subconjunto de operadores revisado, un esquema de variables fijo y componentes de salida fijos. No permitas esquemas o autoridades arbitrarios, y aun así aplica listas de permitidos de origen, normalización de rutas, comprobaciones de DNS/IP y revalidación de redireccionamientos después de la expansión.
Pregunta de seguimiento 4: ¿Puede un modificador de prefijo truncar un secreto?
Es la semántica de prefijo de cadena de URI Template, no un enmascaramiento de privacidad ni un truncamiento seguro para Unicode. Enmascara los datos confidenciales en la capa de negocio, donde la longitud y los límites de caracteres sean una política explícita.
Pregunta de seguimiento 5: ¿Cómo demuestras la compatibilidad con RFC 6570?
Ejecuta los ejemplos de la especificación RFC 6570 y las pruebas a nivel de operador, compara la expansión esperada para cada tipo de variable, luego agrega casos de rechazo específicos del proyecto y documenta los niveles no admitidos y las diferencias.