Valores predefinidos para parâmetros inicio e fim nas consultas

[renatofrota]

Boa tarde,

sugiro que os PSPs possam presumir valores predefinidos para os campos inicio e fim nas consultas onde esses campos hoje são obrigatórios.

Valores predefinidos propostos

inicio => 24h atrás fim => agora

Exemplos

• ao não passar nenhum dos dois parâmetros, o retorno englobaria as últimas 24h;
• passando apenas início equivalente a "1 hora atrás" o fim continuaria sendo presumido como "agora";

Argumentos

• consultar as últimas 24h é, de longe, o cenário mais comum de consulta;
• parâmetro fim pode ocasionar problemas em caso de divergências de alguns segundos entre EC e PSP;
• economizaria bytes trafegados nas consultas;
• economizaria bytes nos registros de logs;
• economizaria desgaste dos dedos ao escrever código;
• economizaria os olhos ao ler logs, históricos e código;
• economizaria dores de cabeça por passagem de eventuais parâmetros incorretos;
• economizaria dores de cabeça para interpretar o intervalo pretendido nas consultas (em logs, históricos e código);
• não mudaria literalmente nada pra quem já passa os parâmetros hoje; e, por consequência
• não causaria qualquer quebra de compatibilidade.

[rubenskuhl]

Em quais chamadas isso se aplicaria hoje ?

[renatofrota]

Em quais chamadas isso se aplicaria hoje ?

As consultas onde esses parâmetros são obrigatórios atualmente:

GET /cob GET /cobv GET /lotecobv GET /loc GET /pix GET /webhook

Entendo que a mudança proposta seria mais efetiva e essencial em:

GET /pix

Mas não vejo prejuízo se aplicada nos demais endpoints, apesar destes parâmetros representarem a data de cadastramento das cobranças/lotes, pelo que eu entendi.

Talvez no /cobv eles representem a data de vencimento? Faria bastante sentido, em se tratando de cobranças com vencimento, mas para a manutenção do padrão onde inicio e fim se referem ao cadastramento, talvez pudessem existir novos parâmetros inicioVencimentoe fimVencimento onde os valores predefinidos sugeridos seriam mais eficientes.

[rubenskuhl]

/webhook não tem parâmetro de tempo na API, e isso se aplica também ao #250.

[renatofrota]

https://bacen.github.io/pix-api/#/Webhook/get_webhook

[rubenskuhl]

Parece ser falha da renderização.

[renatofrota]

Não. Você está olhando o PUT.

https://bacen.github.io/pix-api/#/Webhook/put_webhook__chave_

[rubenskuhl]

Mesmo caso.

[renatofrota]

Esse aí é o GET /webhook/{chave}.

Existe o GET /webhook (sem path params).

[rubenskuhl]

Ah, este. Muito exótico. Acho que sobrou de algum copy/paste.edit. Mais simples remover essa possibilidade do que atribuir um intervalo de tempo.

[renatofrota]

Sim. Mas essa discussão sobre o GET /webhook fazer sentido ou não, faz mais sentido ir lá para o #250.

Esta issue aqui é voltada à sugestão de valores predefinidos para inicio e fim nas consultas (em especial GET /pix). 😉

[renatofrota]

@ninrod ,

achei agora onde eu tinha lido que esses parâmetros eram opcionais (motivo do meu estranhamento ao ler posteriormente que eram obrigatórios). No manual de padrões de iniciação pix, seção 6. Casos de Uso:

O software de automação do usuário recebedor consulta, por meio da API Pix, os últimos Pix recebidos com aquele txid: Serviço invocado: GET /pix?txid={txid} → Podem ser informados parâmetros para limitar a consulta aos últimos minutos, por exemplo (parâmetros “início” e “fim” podem ser usados).

Destaque para o "podem" (não "devem").

[ninrod]

Boa tarde,

sugiro que os PSPs possam presumir valores predefinidos para os campos inicio e fim nas consultas onde esses campos hoje são obrigatórios.

Valores predefinidos propostos inicio => 24h atrás fim => agora

Exemplos ao não passar nenhum dos dois parâmetros, o retorno englobaria as últimas 24h; passando apenas início equivalente a "1 hora atrás" o fim continuaria sendo presumido como "agora"; Argumentos consultar as últimas 24h é, de longe, o cenário mais comum de consulta; parâmetro fim pode ocasionar problemas em caso de divergências de alguns segundos entre EC e PSP; economizaria bytes trafegados nas consultas; economizaria bytes nos registros de logs; economizaria desgaste dos dedos ao escrever código; economizaria os olhos ao ler logs, históricos e código; economizaria dores de cabeça por passagem de eventuais parâmetros incorretos; economizaria dores de cabeça para interpretar o intervalo pretendido nas consultas (em logs, históricos e código); não mudaria literalmente nada pra quem já passa os parâmetros hoje; e, por consequência não causaria qualquer quebra de compatibilidade.

Acho interessante a proposta e está bem fundamentada.

[renatofrota]

@ninrod

em relação a 2.2.1-rc.0: vi que essa issue (249) foi mencionada como tendo refletido na mudança do endpoint GET /webhook. Porém, minha intenção era que essa sugestão se refletisse em todos os endpoints onde os campos hoje são requeridos (em especial GET /pix).

Talvez as discussões posteriores ao comment https://github.com/bacen/pix-api/issues/249#issuecomment-742630632 tenham interferido um pouco nesse direcionamento. Ou a sugestão foi descartada?

[ninrod]

Porém, minha intenção era que essa sugestão se refletisse em todos os endpoints onde os campos hoje são requeridos (em especial GET /pix).

Eu sei. Foi nessa linha, apenas porque ela tocou no caso do /webhook. A sugestão não foi descartada, apenas não consegui introduzir agora. Movi para uma possível 2.3.X.