E. g. localhost:8080/fetch_latest_prices?tickers=ITSA4&tickers=SQIA3 resultaria no backend recebendo uma variável tickers do tipo String[] com o valor ["ITSA4", "SQIA3"].
Isso entretanto não é recomendável, pois diferentes parsers de URL adotam diferentes estratégias pra lidar com repetições de parâmetros do GET. No caso dessa que estamos usando pra API, ele devolve o valor de todas as instâncias do parâmetro em uma lista. Entretanto esse comportamento não é ubíquo. Muito pelo contrário, cada biblioteca interpreta de um jeito. Isso pode se tornar problemático e perigoso se resolvermos mudar de biblioteca para receber requests da API, se resolvermos colocar outro parser na frente da API (e.g. load balancer), entre oturos.
Isso eventualmente deve ser corrigido para garantir estabilidade e segurança do serviço. Uma solução simples seria mudar o endpoint para receber uma lista via POST.
Atualmente a API utiliza multiplas instâncias do mesmo parâmetro para criar "listas" usando o método GET.
https://github.com/Bezunca/API/blob/d87494ac1ebf6e84f000f935fc3124b25301cd93/internal/app/controllers/b3/fetch_latest_prices.go#L39
E. g.
localhost:8080/fetch_latest_prices?tickers=ITSA4&tickers=SQIA3resultaria no backend recebendo uma variáveltickersdo tipoString[]com o valor["ITSA4", "SQIA3"].Isso entretanto não é recomendável, pois diferentes parsers de URL adotam diferentes estratégias pra lidar com repetições de parâmetros do GET. No caso dessa que estamos usando pra API, ele devolve o valor de todas as instâncias do parâmetro em uma lista. Entretanto esse comportamento não é ubíquo. Muito pelo contrário, cada biblioteca interpreta de um jeito. Isso pode se tornar problemático e perigoso se resolvermos mudar de biblioteca para receber requests da API, se resolvermos colocar outro parser na frente da API (e.g. load balancer), entre oturos.
Isso eventualmente deve ser corrigido para garantir estabilidade e segurança do serviço. Uma solução simples seria mudar o endpoint para receber uma lista via POST.