Executando verificação de segurança...
Respondendo a "Normalmente vejo que DELETE com corpo de requis..." dentro da publicação [Não disponível]
1

Normalmente vejo que DELETE com corpo de requisição não é uma boa prática

Por que não seria? É a mesma coisa de um post para criação de models em massa

Carregando publicação patrocinada...
2
  • RFC 2731: "The requestBody is only supported in HTTP methods where the HTTP 1.1 specification RFC7231 has explicitly defined semantics for request bodies".

A própria RFC 2731 menciona que o verbo DELETE não possui uma semântica definida, o que levanta a dúvida: isso significa que "não é ideal usar o método DELETE com um corpo de requisição" ou que "a decisão é sua, faça como preferir"?

2

Ótimo ponto! Embora a RFC não proíba o uso de um corpo em requisições, também não define claramente seu propósito, especialmente no contexto de métodos como DELETE.

Como normalmente associamos o método POST à criação ou envio de dados para um recurso, enquanto DELETE está ligado à remoção de recursos. Usar POST para deletar pode, portanto, contradizer essa expectativa semântica.

Por outro lado, a RFC também não garante que servidores ou frameworks tratarão corpos de requisições DELETE de maneira uniforme. E talvez daí venham as incertezas quanto à confiabilidade dessa abordagem.

Diante disso, parece não haver uma "resposta certa" universal. Caso optemos por DELETE, devemos verificar se a infraestrutura e frameworks suportam corpos de requisição para esse método.

Se decidirmos usar POST para operações fora do padrão, devemos nos certificar de documentar a escolha de forma clara no design da API. Isso ajudaria a minimizar ambiguidades e problemas de interoperabilidade.

1

Uma vez que a REST não seja uma obrigação e sim um padrão, e, essa 'regra' é clara, eu continuaria usando DELETE com um payload, mas sou eu que construo a api, então sei o que posso ou não fazer e vai funcionar.

Já para quem não tem essa certeza, não utilize o post com 'desvio de função', utilize PATCH com payload.