Uso do método DELETE para mensagens de eliminação no /transactions

Propósito

O objetivo desse grooming é decidir pela manutenção do uso do verbo HTTP DELETE no canal REST para submeter mensagens de eliminação de entidades usando o endpoint /transactions.

Ata

Durante a reunião, verificamos que o motivo do uso do método DELETE para indicar a eliminação de entidades era manter coerência entre o método HTTP e a finalidade da mensagem, conforme preconiza as boas práticas do padrão REST.

Entretanto, com a utilização do formato JSON no canal AMQP, verificou-se que tal convenção era insuficiente para informar ao destino a finalidade da mensagem, principalmente no caso de eliminação.

Além disso, com o passar do tempo, verificou-se que o evento da mensagem (inclusão ou eliminação) é um dado da própria mensagem, que interessa ao aplicativo de destino, e não ao canal. Por este motivo, a vinculação de um atributo da mensagem ao canal mostrou-se pouco eficaz, quando o canal não fornece elementos equivalentes ao evento, como ocorre com o canal AMQP.

Durante a reunião, aproveitamos para decidir também sobre:

• O retorno da mensagem do tipo Receipt no canal REST e AMQP.
• A nova proposta de fluxo de mensagem assíncrona, já discutida em grooming anterior.

Conclusões

Ficou decidido pelos participantes do grooming que:

• O método POST será o método preferencial para o canal REST.
• O método DELETE será mantido para recebimento, por compatibilidade.
• Será necessário avisar os parceiros que implementaram o endpoint /transactions da mudança para o método POST, e que o DELETE será depreciado em breve.
• As alterações nas marcas devem ser sincronizadas, sendo que o Protheus precisa liberar as alterações até nov/18.
• A mensagem do tipo Receipt será utilizada nos canais REST e AMQP.
• Será implementado o novo fluxo de mensagem assíncrona, descrito no grooming Revisão do fluxo de mensagem assíncrona.

Ações

• Planejar a implementação do suporte ao método POST para todas as operações e a depreciação do método DELETE.
  • Talvez seja necessário um spike sobre como depreciar o método DELETE.
• Planejar a implementação do Receipt nas linhas para o canal REST/AMQP.
• Planejar a implementação do novo fluxo assíncrono.
• Alterar as documentações pertinentes, principalmente as que definem o uso do método DELETE e as que determinam a forma de resposta em caso de mensagem assíncrona.