Executando verificação de segurança...
1

Concordo com quase tudo, só mudaria o final pra PUT (considerando que só esta atualizando o status do chat)
PUT /chats/:id/transfer
PUT /chats/:id/close
PUT /payments/:id/refund
PUT /subscriptions/:id/cancel

Carregando publicação patrocinada...
1

Boa Pedro! Eu conversei com outras pessoas sobre esse assunto, e também surgiu essa sugestão de usar o PUT, como também de usar o PATCH. Pra mim me parece um pouco estranho usar esses métodos sem enviar nenhum dado pra ser alterado/substituído. Uma pessoa até brincou, que devia existir o método ACTION hahah.

Uma informação que achei bem interessante pra refletir é que o PUT deve ser idempotente, logo ao ocorrer 2 requisições idênticas, a segunda não deveria causar uma operação diferente no registro. Mas é algo que poderia ocorrer com essas ações, com 2 requisições ocorreriam 2 estornos de um pagamento (considerando estorno de valores parciais).

Mas assim, vejo que não tem um super consenso quanto a isso, não sinto que as especificações do REST cobrem exatamente esse cenário, então acho válida sua opinião.

Por exemplo, a API da Recurly (líder global em API de assinaturas recorrentes) usa o PUT nessas rotas de ações, ao invés de POST, ex.: 'PUT /subscriptions/:id/cancel'.

Já o Stripe (referência em Developer Experience) usa o DELETE, mas usa 'POST /payouts/:id/cancel' pra cancelar um saque e 'POST /charges/:id/capture' pra capturar uma cobrança.