Cómo Usar Parámetros de Consulta URL

Añadir parámetros de consulta a una solicitud

Puedes añadir parámetros de consulta a tu solicitud, ya sea en la URL o en el campo de Parámetros de Consulta.

https://www.example.com?query1=value1&query2=value2
https://www.example.com?query1=value1&query2=value2#hash1
https://api.example.com/v2/resources/1?query1=value1&query2=value2

Ambos métodos son válidos; si añades parámetros de consulta en la URL y también en los campos de Parámetros de Consulta, se concatenarán y se usarán todos los parámetros de consulta.

Por qué los parámetros de consulta importan en una prueba de carga

Los parámetros de consulta forman parte de la URL de la solicitud, así que el servidor (y cualquier cosa delante de él, como una CDN, un proxy inverso o un WAF) los ve como parte de lo que se le está pidiendo. Esto importa de dos maneras durante una prueba de carga:

• Enrutamiento y filtrado: muchas APIs usan parámetros de consulta para seleccionar un recurso, una página o un filtro (?page=2, ?status=active, ?locale=en). Si tu prueba siempre golpea la misma combinación de parámetros, solo estás probando una ruta de código. Un endpoint de búsqueda que es rápido para ?q=shoes puede comportarse de forma muy distinta con ?q= (vacío) o con una consulta con muchos filtros aplicados a la vez.
• Caché: una CDN o un proxy inverso normalmente trata la URL completa, incluida su cadena de consulta, como clave de caché. Añadir un parámetro de consulta que cambia en cada solicitud (una marca de tiempo para evitar la caché, un id aleatorio) puede convertir sin querer un endpoint cacheable en uno que falla la caché en cada usuario virtual. Eso parecerá un backend mucho más lento y mucho más cargado de lo que el tráfico de producción produciría jamás, cuando la causa real es la propia cadena de consulta.

Parámetros estáticos frente a valores por solicitud

Los parámetros que escribes en una solicitud de prueba son estáticos: cada usuario virtual envía exactamente la misma cadena de consulta en cada iteración. Esto está bien para la mayoría de las pruebas conceptuales (verificar que un endpoint se comporta correctamente y se mantiene rápido bajo carga), pero ten en cuenta dos cosas:

• No puedes hacer que un parámetro de consulta sea "global" y que se aplique automáticamente a cada solicitud de la prueba, por ejemplo una clave de API pasada como ?api_key=.... Debe añadirse a cada URL de solicitud (o campo de Parámetros de Consulta) individualmente, donde se necesite.
• Si el endpoint que estás probando espera un valor distinto en cada llamada, un cursor de paginación, un id de pedido único, un token de un solo uso, una cadena de consulta fija solo ejercitará ese único valor, repetido. El tráfico real llega con muchos valores distintos, así que los resultados basados en un valor estático te hablan de ese caso concreto, no del rango completo de comportamiento en producción.

Errores comunes

• Olvidar codificar la URL: los espacios, &, = y otros caracteres reservados dentro de un valor deben codificarse en porcentaje, de lo contrario la cadena se interpreta como parámetros adicionales en lugar de un único valor.
• Confundir el fragmento con un parámetro: cualquier cosa después de # (como #hash1 en el ejemplo anterior) es un fragmento de URL, no un parámetro de consulta. Los navegadores mantienen los fragmentos del lado del cliente y nunca los envían al servidor, así que no tienen ningún efecto en las pruebas de carga del lado del servidor.
• Duplicar un parámetro en ambos sitios: dado que los valores de la URL y del campo de Parámetros de Consulta se concatenan, añadir la misma clave en ambos sitios la envía dos veces, lo que puede provocar un comportamiento distinto, y no deseado, en servidores que solo esperan un valor por clave.

Para más orientación relacionada, consulta https://loadfocus.com/docs/es-es/knowledge-base/using-valid-url-endpoints y https://loadfocus.com/docs/es-es/guides/load-testing/how-to-url-query-parameters.