[Dúvida] no [Pix Api] - Api Recebimentos (V1) é considerada obsoleta?

[randrade86]

Com o release da API PIX v2, podemos considerar a API v1 como obsoleta e que não deve ser utilizada por nenhum participante?

Sistema ou Área
Iniciação de Pagamentos

[ninrod]

@randrade86, a API 1.x.x pode ser considerada obsoleta e a 2.x.x é a atual.

Como a API ainda não está em produção, nós achamos "estranho" já começar a partir da versão v2. Por outro lado, será que não seria interessante existir um "match" entre v{n} e {n}.x.x e tudo bem se "começar" em v2? Pensando agora até acho que fica mais "coeso".

O que acha?

cc: @rturk? @rubenskuhl? @oximer? Opiniões?

[rubenskuhl]

Eu acho que o v2 acaba refletindo o fato de que muitas organizações vinham trabalhando em APIs proprietárias, mesmo durante o desenvolvimento das versões 1.x, até que o BACEN fez um comunicado onde ficou claro que a única API permitida seria a padronizada (o que para mim já estava claro antes, mas que não era a percepção de várias instituições). Eu sugiro manter sim o match.

Já para o regulamento, sugiro especificar quando uma API obsoleta deixa de poder ser usada.

[rubenskuhl]

Em tempo: https://www.bcb.gov.br/estabilidadefinanceira/pagamentosinstantaneos ainda tem link para a versão 1.2.0.

[oximer]

@randrade86, a API 1.x.x pode ser considerada obsoleta e a 2.x.x é a atual.

Como a API ainda não está em produção, nós achamos "estranho" já começar a partir da versão v2. Por outro lado, será que não seria interessante existir um "match" entre v{n} e {n}.x.x e tudo bem se "começar" em v2? Pensando agora até acho que fica mais "coeso".

O que acha?

cc: @rturk? @rubenskuhl? @oximer? Opiniões?

Também não vejo problemas em trabalharmos com a v2.

[rturk]

Sobre nomenclatura:

Recomendo que esta API evolua considerando as boas práticas de semver. Desta forma deverá se chamar pelo exato nome que tem, ou seja v2.

Sou grande fã da imutabilidade de standards. Padrões estáveis ajudam a criar códigos estáveis e principalmente trazer celeridade e confiança ao sistema. Se a primeira versão da API foi originalmente foi descrita como v1 sempre devemos representar esta como tal, ou seja, v1 e a nova como v2.

Isto também ajuda a discussão nos fóruns, e discussões técnicas, alguém poderá facilmente comentar das evoluções entre v1 e v2 e no futuro v3 etc. O grande benefício de ter versões é poder justamente comparar uma contra as outra e aprender com o passado.

Sobre obsolescencia da V1

Recomendo fortemente que a v1 seja decretada como obsoleta, dado que esta nunca chegou a entrar em produção. Dada a importância destas APIs para o sistema financeiro nacional é de extrema importância para todos os stakeholders ter certeza de qual API está em vigor.

[rubenskuhl]

Seguem respostasque eu tive de uma instituição financeira. Parece prudente emitir um alerta já que eles estão relutando em entender.

Pergunta: A autenticação não é OAuth2, diferente do que o BACEN especificou (https://github.com/bacen/pix-api/blob/2.0.0/openapi.yaml):
Resposta: O Bacen alterou dia 18/09 a APIREC, porém não formalizou, os manuais permanecem os mesmos. Não estamos descumprindo a regra, usamos a especificação que existia até então (versão 1.2). Exatamente por esse motivo temos o disclaimer de futuras alterações no manual.

Pergunta: Os métodos chamados não estão claros, e parecem divergentes dos métodos especificados na API do BACEN (/cob, /pix, /webhook)
Resposta: utilizamos a versão 1.2.

Pergunta: O call-back assíncrono não está disponível (/webhook) enquanto ele está previsto na API do BACEN e é essencial para uma integração escalável
Resposta: Sim, ele ainda não está disponível.

[dmkamers]

Em tempo: https://www.bcb.gov.br/estabilidadefinanceira/pagamentosinstantaneos ainda tem link para a versão 1.2.0.

Caros, foi atualizado ontem.

[ninrod]

Caros, vamos de v2. Será atualizado na 2.1.0 a ser disponibilizada "em breve".