bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.23k stars 257 forks source link

PUT deveria efetuar alteração/revisão? #571

Open johngalt85 opened 8 months ago

johngalt85 commented 8 months ago

Um PUT no recurso /cob ou /cobv, deveria fazer alteração? Pois existe o PATCH para isso, não é? Além de um verbo específico para alteração, permitir que o PUT o faça também, não é errado, uma vez que deveria rejeitar a criação por TXID já existente?

rubenskuhl commented 8 months ago

Me parece que não deveria poder fazer alteração, já que isso quebra idempotência. Apenas PUT com os mesmos dados anteriores deviam ser aceitos IMHO.

johngalt85 commented 8 months ago

Minha aplicação estava equivocadamente enviando um mesmo Txid para o recurso PUT /cob, com outros dados de cobrança, como se fosse uma nova cobrança de fato, só mantendo o Txid, porém a cada PUT a cobrança era alterada, já identifiquei e corrigi. Porém, meu questionamento é se o fato de estar usando PUT /cob, a requisição não deveria simplesmente ser recusada por Txid já existente? Reforçando esse argumento, o fato de já existir o PATCH /cob com a finalidade específica de alteração, porém lendo a documentação(swagger, spec) não localizei nada taxativo em impedir que PUT /cob faça alteração, para que eu possa questionar o PSP Recebedor fornecedor da API, de forma embasada na documentação BACEN.

rubenskuhl commented 8 months ago

Minha aplicação estava equivocadamente enviando um mesmo Txid para o recurso PUT /cob, com outros dados de cobrança, como se fosse uma nova cobrança de fato, só mantendo o Txid, porém a cada PUT a cobrança era alterada, já identifiquei e corrigi. Porém, meu questionamento é se o fato de estar usando PUT /cob, a requisição não deveria simplesmente ser recusada por Txid já existente? Reforçando esse argumento, o fato de já existir o PATCH /cob com a finalidade específica de alteração, porém lendo a documentação(swagger, spec) não localizei nada taxativo em impedir que PUT /cob faça alteração, para que eu possa questionar o PSP Recebedor fornecedor da API, de forma embasada na documentação BACEN.

Por mais que eu ache isso uma violação de idempotência, a documentação do BACEN ampara o que fez o PSP nesse caso:

__Violações__ específicas para o endpoint `PUT /cob/{txid}`:
      - A cobrança já existe, não está no status ATIVA, e a presente requisição busca alterá-la.

Ou seja, o que diz o BACEN é que uma cobrança ATIVA (ou seja, nem paga nem removida) pode ser alterada via PUT, não apenas via PATCH.