Validação URL do Location

[mvleandro]

Até semana passada, constava no Manual de Padrões para Iniciação do Pix, que o fragmento de versão na URL do Payload era obrigatório.

Com o lançamento da Api do Pix 2.3.0 na semana passada isto parece ter mudado. Tanto que há cenários de Cobrança Imediata Válida na ferramenta QRTester, onde não há fragmento de versão na url do payload.

Minha dúvida é: Neste caso, quando não há fragmento de versão na URL, qual versão deve ser considerada como padrão?

Dou uma sugestão: por se tratar de uma breaking change, este ponto deveria ganhar mais destaque nos comunicados oficiais do Banco Central.

Outro ponto: Entendo que a api do pix segue o versionamento semântico e, portanto, não deveria haver quebra de contratos ou de funcionalidades sem que haja o incremento da Major Version. Pretende-se alterar o padrão de versionamento da Api para outro customizado? Senão, houve erro na nomenclatura da última versão da api, uma vez que ocorreu quebra de contrato?

[mvleandro]

@ninrod

[ninrod]

Olá @mvleandro

Neste caso, quando não há fragmento de versão na URL, qual versão deve ser considerada como padrão?

v2

por se tratar de uma breaking change, este ponto deveria ganhar mais destaque nos comunicados oficiais do Banco Central.

Por que você acha que é uma breaking change?

[mvleandro]

É um breaking change de contrato. Pois, a versão anterior tinha como mandatória a presença do fragmento v2 na url e obrigava os participantes a validarem a url em busca deste formato.

Agora, como a presença não é mais obrigatória, os testes de falha falham, ou seja, a ausência do fragmento v2 não causa mais quebra de contrato, alterando o comportamento das apis e o formato da url.

Em outras palavras: na versão anterior, uma url sem o fragmento v2 era uma url inválida. Na versão atual, ela passou a ser uma url válida. Isto em si, configura uma quebra de contrato.

[mvleandro]

@ninrod

[ninrod]

@mvleandro , bom dia dia.

e obrigava os participantes a validarem a url em busca deste formato.

Sim. Obrigava os apps dos PSPs pagadores a validarem a presença do v2. Não obriga mais. Então, no final da etapa homologatória vigente, que deve ser em maio, nenhum PSP pagador deve rejeitar QR Codes que apareçam sem essa partícula.

Agora, como a presença não é mais obrigatória, os testes de falha falham, ou seja, a ausência do fragmento v2 não causa mais quebra de contrato, alterando o comportamento das apis e o formato da url.

Apenas esclareço que a API continua se comportando como estava se comportando. Essas validações da presença do v2 foram removidas do QR Tester. Além disso, qualquer location que apresente v2 continua sendo válida. Não vejo como "alteração do comportamento das APIs". O que foi alterado foi o formato da location, que, vale dizer, ainda comporta o v2 (e o que mais o PSP quiser colocar). O impacto aqui é diretamente no PSP do pagador que não deve mais rejeitar locations que não exibam o `v2.

Em outras palavras: na versão anterior, uma url sem o fragmento v2 era uma url inválida. Na versão atual, ela passou a ser uma url válida. Isto em si, configura uma quebra de contrato.

Por mais que se tente perseguir establidade na API, as vezes é necessário. Concordo com você que semanticamente é uma quebra porque antes certas locations que eram inválidas, o deixam de ser. Por outro lado, por entender o impacto, o BCB tomou certas decisões para lidar com o impacto. Neste caso, acredito que a situação está sob controle: o escopo do impacto está bem mapeado, foi por um bom motivo, bem fundamentado. Os únicos impactados por essa mudança são os apps PSP do pagador e não os outros clientes da API (usuário recebedor, por exermplo, impacto zero). Os PSPs pagadores estão em um processo de homologação, contando com um prazo razoável para adequação (a duração da fase de homologação foi estendida), o QR Tester está validando os cenários envolvendo a questão da remoção da versão e há tempo hábil para se adaptar às mudanças.