Ola!
Estou desenvolvendo uma API em Spring boot e existe um cenário em que eu tenho que chamar a API novamente mas dentro da própria API. Alguém já teve que fazer isso?
Mas pq esse overhead? Poderia chamar diretamente o service.
@javaflex Eu faço uma consulta passando um dia poe exemplo (20/01/2020) se não tiver informações tenho que chamar a API novamente com a próxima data (21/01/2020). Entendeu?
Cara, não precisa desse overhead, deveria ser uma verificação direta no banco.
1 curtida
Vc não chama a api, dentro da própria api.
Vc chama métodos da api, dentro da api.
Se for pra consultar pelo próximo dia existente na relação a solução do @javaflex é a mais econômica/melhor.
Outra solução seria usar a recursividade, mas não seria tão eficiente pois teria que ficar consultando o banco de dados sem necessidade.
Vc pode resolver isso com um SELECT, ex:
SELECT * from produto where produto.data >= _data_buscada limite 1;
1 curtida
A metodologia pelo banco citada acima é a melhor, mas para efeitos didaticos. Vamos as outras.
Por algum motivo aleatorio, vc pode retornar uma lista vazia, e o cliente que realiza essa nova requisicao, com uma nova data. Isso ao primeiro momento, pode parecer a pior alternativa, mas ha determinadas regras de negocio q precisam disso.
Segundo dentro do mesmo metodo, vc verificando que não ha nenhum resultado, vc pode usar o metodo plusDays, das classes LocalDate e LocalDateTime para somar mais um dia a data e realizar, isso dentro do mesmo metodo.
Se a lista retorna vazia, é porque não há o que ser buscado.
Quem projetou o sistema não entende tautologia ou não sabe o que está fazendo.
No presente caso não há justificativa para ficar ocupando o servidor, o cliente, o desenvolvedor, o banco de dados e a linha telefônica.
Isso se chama inexperiência.
Pois a exemplo da recursividade exigiria conhecer a flag de saída, provavelmente arbitrária, mais custosa, portanto mais cara para o servidor.
Seria necessário chamar o cliente para perguntar qual a data limite atrasando o tempo de conclusão do projeto.
Além disso é uma alternativa mais trabalhosa para implementar, aumenta de forma desnecessária o processamento e não libera a conexão do banco de dados.
Só o gancho para consultar o cliente já representa um aumento de custos, que se for cultural representa um grande problema.
Não há benefício justificável.
Calma ai amiguinho, como tinha dito o melhor caminho é pelo sql, tem inumeros o porque.
Sobre os caminhos q citei, o primeiro é uma lista vazia, e as vezes é só isso que o cliente deseja essa lista vazia, se ele desejar a lista do dia 21, ele o decidirá se ira ou nao fazer essa requisição, as vezes não precisamos pensar muito, o complicado é simples.
O segundo caminho é bem porco, não é a resposta correta mas pode ajuda-lo em alguma outra questão essa soma de datas.
Hoje o cliente passa duas dadas (inicio e fim) por exemplo 15/01/2020 e 21/01/2020.
Eu tenho que retornar pra ele um dia por vez só que no dia que não tiver informações devo ir para o próximo dia. Essa regra já foi definida e não é possível alterar. Por isso perguntei como faço pra chamar novamente a API.
O segundo caso não depende diretamente do cliente, seria chamar o método novamente. Mesmo o segundo caso sendo bem porcão ainda posso pensar em possível caso de uso.
Que em caso de uma resposta vazia, vc deve executar uma lógica aleatória, e então fazer uma nova requisição ao banco, tudo é possível, pois tudo depende da logica de negócio do seu cliente.
public List<Object> metodo(LocalDate date){
var lista = consultaDados(date);
if(lista.isEmpty()){
//Executa uma lógica aleatória
// Só então
lista = metodo(date.plusDays(1));
}
return lista;
}A resposta anterior foi para o Pedreiro de software no seu caso é so fazer o sql pedindo os valores entre data x e y usando o BETWEEN, e ir retornando dia a dia.
O problema, não é fazer errado, o problema é fazer errado ao estar ciente da forma mais eficiente.
O que vai agradar mais ao chefe.
Uma solução simples ou menos simples?
@Homario,
Não entendi.
É para retornar um dia dentro do intervalo?
Ou é para retornar todos os dias dentro do intervalo?
Em ambos os casos, não é necessário ficar fazendo requisições pra implementar um filtro com base em dias.
Foi demandado que vc chamasse a Api, dentro da Api ou essa é uma dedução sua???
Se for uma dedução sua, é só esnobar e gastar 30 segundos ajustando o sql.
1 curtida
@PedreiroDeSoftware, é necessário retornar o intervalo só que dia por dia. Se o cliente quiser 5 dias de informações eu tenho que disponibilizar o dia 1 e dar o link pra ele consultar o próximo dia. Isso é o desenho da API mas o que tenho que fazer é quando vier um dia que não tem informação eu devo consultar o próximo que que tenha dados e assim ate o ultimo dia.
Vcs vão fazer essa paginação na unha também?
Boa sorte na implementação, se não conseguir chamar a api de dentro da api pode fazer o mesmo com javascript, mas o cara deve ficar puto de ter que construir um método pra ficar de bate papo com o servidor.
Rapaz, pense logo na rotatividade, porque quem desenhou esse negócio ta facilitando sua vida não.
Nem eu que estudei pra ser pedreiro e tenho formação em gambiarra.
Não vejo por que de tanta complicação nessa caso amigo, eu mesmo já fiz semana passada algo bem parecido oque você precisa fazer é apenas uma consulta dentro de um range de datas(ao menos foi oque eu entendi), se o cliente de passa uma data inicio e uma final, ao cair no seu beckend você pode fazer um método para pegar o range dessas datas incluindo elas mesmas e ir fazendo a consulta e adicionar as datas numa lista, por exemplo te passara as datas 01/01/2019 - 04/01/2019 faça um método para retornar uma lista com as datas: 01/01, 02/01, 03/01, 04/01 de 2020
em outro método receba essa lista e faça um loop por data e construa uma nova lista com seus dados.
Na verdade a API já esta pronta. Eu só preciso “ajustar” rs
O problema é a quantidade de informações… Se fosse poucos dados seria mais simples.