Descrição do problema:
Ao utilizar do endpoint:
GET https://brasilapi.com.br/api/ibge/municipios/v1/{siglaUF}?providers=dados-abertos-br,gov,wikipedia
A API retorna apenas dois tipos de resultados:
200 - Quando a UF é válida
404 - Not Found quando a UF é inválida, inexistente ou mal formatada.
Essas respostas limitadas faz com que qualquer erro, seja ele de entrada (como UF com números, muitos ou poucos caracteres e etc) ou erro interno do servidor, retorne como resposta 404 mesmo que o erro não seja a ausência de resultados.
Seria mais adequado que que a API distinguisse o tipo de erro de acordo com o problema encontrado, tendo novas respostas como:
400 - Bad request
404 - Not Found
422 - Unprocessable Entity
500 - Internal Server Error
Benefícios da melhoria:
Facilita o tratamento de erros em aplicações clientes.
Melhora a clareza das respostas e a experiência do desenvolvedor.
Torna o uso da API mais consistente boas práticas.
Descrição do problema:
Ao utilizar do endpoint:
GET https://brasilapi.com.br/api/ibge/municipios/v1/{siglaUF}?providers=dados-abertos-br,gov,wikipedia
A API retorna apenas dois tipos de resultados:
200 - Quando a UF é válida
404 - Not Found quando a UF é inválida, inexistente ou mal formatada.
Essas respostas limitadas faz com que qualquer erro, seja ele de entrada (como UF com números, muitos ou poucos caracteres e etc) ou erro interno do servidor, retorne como resposta 404 mesmo que o erro não seja a ausência de resultados.
Seria mais adequado que que a API distinguisse o tipo de erro de acordo com o problema encontrado, tendo novas respostas como:
400 - Bad request
404 - Not Found
422 - Unprocessable Entity
500 - Internal Server Error
Benefícios da melhoria:
Facilita o tratamento de erros em aplicações clientes.
Melhora a clareza das respostas e a experiência do desenvolvedor.
Torna o uso da API mais consistente boas práticas.