Adicionando ddd no retorno da busca pelo cep referente a issue aberta #416

[Carlosvpm]

A alteração consiste na adição de uma função que busca o DDD da região pelo nome da cidade retornado pelo end-point ja existente do cep, utilizei os recursos ja existentes no módulo de ddd.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
brasilapi	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 6, 2023 4:18pm

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[LorhanSohaky]

@Carlosvpm , será que vale a pena criar um endpoint que seja /v1/cep-e-ddd ou /v3/cep?

Só para explicar em mais detalhes... O endpoint v2 já é mais demorado que o v1 poq ele precisa bater em outro fornecedor de dados para pegar a geolocalização aproximada. E com a adição do dado do ddd isso ficará mais demorado.

Uma outra opção que não degrada no quesito tempo de execução e acho bem interessante é adicionar suporte a HATEOAS (#329). Nessa situação sugeriria criar um /v3/cep com esse link para consultar o ddd sem afetar a performance da rota

[Carlosvpm]

@Carlosvpm , será que vale a pena criar um endpoint que seja /v1/cep-e-ddd ou /v3/cep?

Só para explicar em mais detalhes... O endpoint v2 já é mais demorado que o v1 poq ele precisa bater em outro fornecedor de dados para pegar a geolocalização aproximada. E com a adição do dado do ddd isso ficará mais demorado.

Uma outra opção que não degrada no quesito tempo de execução e acho bem interessante é adicionar suporte a HATEOAS (#329). Nessa situação sugeriria criar um /v3/cep com esse link para consultar o ddd sem afetar a performance da rota

@LorhanSohaky, Realmente, não me atentei para a performance do recurso, fiz a medição das implementações e a diferença foi de quase 4x o tempo na V2 implementada, em contrapartida utilizando o padrão HATEOAS o tempo de execução diminui significativamente.
Desse modo, manterei com o padrão HATEOAS. Porém, creio que não seja a melhor escolha pra quem esteja consumindo, porque irá fazer mais requisições que o necessário. talvez se conseguirmos fazer algo como o graphQL faz, seja a melhor opção neste caso. Precisarei estudar outras opções. Agradeço pelo feedback!! TMJ!

[LorhanSohaky]

Uma coisa que me ocorreu agora....

Se for muito importante vir o dado de DDD na resposta da API, você pode colocar uma parâmetro para incluir ou não esse dado na resposta /v3/cep/12345?ddd=true e na resposta já vem o DDD. E para melhorar a performance você pode tentar paralelizar o request de geolocalização com o ddd. Além disso, seria interessante se fosse possível algum tipo de "memo" para evitar de fazer requisição ao provedor do DDD, isso tornaria a API rápida

[LorhanSohaky]

@lucianopf , @murilohns , o que acham?

[lucianopf]

Uma coisa que me ocorreu agora....

Se for muito importante vir o dado de DDD na resposta da API, você pode colocar uma parâmetro para incluir ou não esse dado na resposta /v3/cep/12345?ddd=true e na resposta já vem o DDD. E para melhorar a performance você pode tentar paralelizar o request de geolocalização com o ddd. Além disso, seria interessante se fosse possível algum tipo de "memo" para evitar de fazer requisição ao provedor do DDD, isso tornaria a API rápida

Curti as propostas hein!
Faria inclusive a busca de geolocalização ser parametrizável tbm 🤔

Talvez não fosse necessário nem criar uma v3 se a gnt manter o padrão da v2 como geo=true&ddd=false pq não quebraria a interface de quem já está consumindo 👀

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information