bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.39k stars 269 forks source link

Período de Consulta online #436

Open biancaOliveiraSantos opened 3 years ago

biancaOliveiraSantos commented 3 years ago

Bom dia!

Existe um período obrigatório para retorno das consultas online da API?

Exemplo: Cliente faz a requisição da api \PIX dos recebimentos Pix de QR e transferências, efetuando a busca por um grande período. Dependendo do volume de pagamentos que o cliente possuir, pode dar um erro de time out.

A instituição pode criar uma regra de "expurgo" de dados online, para performar o retorno das APIs, disponibilizando outra forma de retorno para grandes volumes/períodos e incluir períodos máximos de busca?

Obrigada!

ninrod commented 3 years ago

@biancaOliveiraSantos , bom dia.

Exemplo: Cliente faz a requisição da api \PIX dos recebimentos Pix de QR e transferências, efetuando a busca por um grande período. Dependendo do volume de pagamentos que o cliente possuir, pode dar um erro de time out.

apenas tentando entender: a paginação não resolve esse problema?

A instituição pode criar uma regra de "expurgo" de dados online, para performar o retorno das APIs, disponibilizando outra forma de retorno para grandes volumes/períodos e incluir períodos máximos de busca?

Essa só o DECEM pode responder em pix@bcb.gov.br

biancaOliveiraSantos commented 3 years ago

Bom dia!

A paginação ajuda, mas não resolve completamente.

ninrod commented 3 years ago

@biancaOliveiraSantos ,

A paginação ajuda, mas não resolve completamente.

Pode entrar em detalhes técnicos?

cryptographix commented 1 year ago

@ninrod, o problema de paginação não resolve, considerando como limite máximo 1000 x cobv por página, uma vez que o payload de cada cobv pode conter um vetor de infosAdicionais[] bem como um vetor de pix recebidos cada qual com devoluções.

Ai, tem dois potenciais problemas: 1) tempo das buscas (sub-selects da base, ou chamadas a microserviços) por exemplo para incluir os pix + devolucoes e 2) tamanho da resposta, considerando eventuais limites corporativos de gateways de APIs etc.

Como dado concreto, temos um caso de gateway com limite de 5MB de retorno, aí, 1000 x cobv = 5KB por cada JSON completo.

No caso do GET /lotecobv com lotes grandes, tanto o custo da consulta como um eventual limite de tamanho pode ser problemático, considerando uma página com 1000 lotes, cada qual com uma lista de cobs[], cada uma contendo txid, status, data e, potencialmente, um Problema com um vetor de violações ..

pedro-meneghel-filho commented 9 months ago

Tem uma outra questão que também vejo como problema com relação ao tempo da query que é o fato de termos que contar quantos registros foram encontrados dentro do período informado para então paginar os resultados.

Um exemplo: um cliente que recebe 100.000 Pix diários via pagamento de COB imediata, tenta obter a listagem de pix recebidos no período de 01/01/2021 à 31/12/2023. Por mais que a primeira página tem um limite de 1.000 pix a serem exibidos, será necessário devolver o valor total de transações no período.

Dado o exemplo, não seria interessante ter um limite no fornecimento dos parâmetros de data? Talvez 12 meses, por exemplo?

Outro ponto é, o cliente vai poder consultar transações "antigas"? Sei que o Pix é algo novo, porém o cliente vai poder solicitar listagem de Pix ocorrido a 6 anos atrás, por exemplo?

rubenskuhl commented 9 months ago

Tem uma outra questão que também vejo como problema com relação ao tempo da query que é o fato de termos que contar quantos registros foram encontrados dentro do período informado para então paginar os resultados.

Um exemplo: um cliente que recebe 100.000 Pix diários via pagamento de COB imediata, tenta obter a listagem de pix recebidos no período de 01/01/2021 à 31/12/2023. Por mais que a primeira página tem um limite de 1.000 pix a serem exibidos, será necessário devolver o valor total de transações no período.

Dado o exemplo, não seria interessante ter um limite no fornecimento dos parâmetros de data? Talvez 12 meses, por exemplo?

Outro ponto é, o cliente vai poder consultar transações "antigas"? Sei que o Pix é algo novo, porém o cliente vai poder solicitar listagem de Pix ocorrido a 6 anos atrás, por exemplo?

Não tem soma de valores de transações de GET no /cob, então não entendi o problema apontado.

Sobre o outro tema, enquanto não houver uma nova definição do BACEN, vai poder consultar desde Novembro de 2020. Se sua casa entende que isso não é ideal, pode propor ao BACEN uma revisão na spec.

pedro-meneghel-filho commented 9 months ago

Acredito que me expressei mal, quando disse valor total queria me referir a quantidade total de registros encontrados com os parâmetros fornecidos (campo quantidadeTotalDeItens).

rubenskuhl commented 9 months ago

Acredito que me expressei mal, quando disse valor total queria me referir a quantidade total de registros encontrados com os parâmetros fornecidos (campo quantidadeTotalDeItens).

Mas aí não é uma questão de correto design de banco de dados para que uma transação COUNT() não seja onerosa ?