API 2.2 - Tratamento de erros e ID Loc único

[biancaOliveiraSantos]

Boa tarde!

Tenho duas dúvidas quanto a documentação da API 2.2.
1- Os tratamentos de erros padronizados são exclusivamente os listados, ou podem ser criadas mais validações?
2- O Id Location deve ser único por PSP emissor ou por cliente (cpf/cnpj)?

[ninrod]

1- Os tratamentos de erros padronizados são exclusivamente os listados, ou podem ser criadas mais validações?

Há validações que podem ser criadas. Particularmente aquelas que estão aderentes ao contexto de funcionamento do PSP. Por exemplo: http 500, "janela de manutenção".

2- O Id Location deve ser único por PSP emissor ou por cliente (cpf/cnpj)?

por cliente (cpf/cnpj)

[felipecamargo]

@ninrod
Se é único a nível de cliente e na entidade de location foi definido que o ID é do tipo Int32, significa que dentro de um curto a médio prazo os clientes (grandes) esgotarão todos os ids possíveis (2.147.483.648).

Eu aconselho a trocar o tipo para UUIDv4 visto que nem todos os clientes pensaram em reutilização de location entre "n" cobranças.

[ninrod]

Eu aconselho a trocar o tipo para UUIDv4 visto que nem todos os clientes pensaram em reutilização de location entre "n" cobranças

Esse é um ponto importante. Não acho que o problema está no cliente, mas sim no PSP. O PSP é que tem que "reaproveitar" os locations porque usar o endpoint /loc vai ser a exceção.

Estamos cientes do problema e eu sei que tornar este campo uma string é a solução técnica superior. Ao mesmo tempo, introduzir alterações retrocompatíveis é algo que temos que perseguir.

[jeffersonf23]

Bem observado @felipecamargo!
@ninrod Talvez alterar para um int64 (9.223.372.036.854.775.807) minimizaria esse impacto?

[mvleandro]

@ninrod

Acredito que este ponto merece uma atenção especial e urgente.

Imagina uma Telecom com clientes a nivel nacional emitindo cobranças Pix mensalmente para todos os seus clientes.

 

Se continuarmos adotando inteiro para definir o id do location, entendo que o Pix não poderá ser utilizado por Telecons, por exemplo. Ou para faturas de cartão de crédito, etc...

 

Entendo que devemos percorrer alterações retrocompativeis, mas o assunto é grave demais. Extamos praticamente excluindo o uso do Pix para estes cenários se isto não for alterado.

 

Sugiro mudarmos o id do location para um guid/uuid e forma urgente.

[ninrod]

@mvleandro

@ninrod Talvez alterar para um int64 (9.223.372.036.854.775.807) minimizaria esse impacto?

Acho que essa seria a alteração com menor impacto. @jeffersonf23 , obrigado pela sugestão.

O que acha?

[rubenskuhl]

Eu gosto do int64 por ser mais retrocompatível. Eu só adicionaria que os possíveis números negativos em int32 devam ser evitados, então pode ser que um espaço de 2^31 ficasse não disponível.

[ninrod]

Eu gosto do int64 por ser mais retrocompatível. Eu só adicionaria que os possíveis números negativos em int32 devam ser evitados, então pode ser que um espaço de 2^31 ficasse não disponível.

@rubenskuhl: Acho que int64 é a nossa melhor opção no momento: https://swagger.io/docs/specification/data-models/data-types/. Se houvesse um tipo "unsigned" seria melhor, mas entendo que não há.

[biancaOliveiraSantos]

@ninrod, para 15 de março essa é a melhor solução, a fim de que os clientes não sejam impactados. Quando essa alteração será contemplada?

[ninrod]

@ninrod, para 15 de março essa é a melhor solução, a fim de que os clientes não sejam impactados. Quando essa alteração será contemplada?

Na 2.2.1, não consigo passar uma data agora. Tentarei mirar, é claro, uma publicação com boa antecedência a 15 de março.