Open renatofrota opened 3 years ago
Em quais chamadas isso se aplicaria hoje ?
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 inicioVencimento
e fimVencimento
onde os valores predefinidos sugeridos seriam mais eficientes.
/webhook não tem parâmetro de tempo na API, e isso se aplica também ao #250.
Parece ser falha da renderização.
Não. Você está olhando o PUT.
Mesmo caso.
Esse aí é o GET /webhook/{chave}.
Existe o GET /webhook (sem path params).
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.
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). 😉
@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").
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.
@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?
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.
Boa tarde,
sugiro que os PSPs possam presumir valores predefinidos para os campos
inicio
efim
nas consultas onde esses campos hoje são obrigatórios.Valores predefinidos propostos
inicio
=> 24h atrásfim
=> agoraExemplos
início
equivalente a "1 hora atrás" o fim continuaria sendo presumido como "agora";Argumentos
fim
pode ocasionar problemas em caso de divergências de alguns segundos entre EC e PSP;