Embora a especificação HTTP 1.1 pareça permitir corpos de mensagem em solicitações DELETE , parece indicar que os servidores devem ignorá-la, pois não há semântica definida para ela.
4.3 Corpo da Mensagem
Um servidor DEVE ler e encaminhar o corpo da mensagem em qualquer solicitação; se o método de solicitação não inclui semântica definida para um corpo de entidade, então o corpo da mensagem DEVERÁ ser ignorado ao lidar com a solicitação.
Já revisei várias discussões relacionadas a este tópico no SO e além, como:
- Um corpo de entidade é permitido para uma solicitação HTTP DELETE?
- Cargas úteis de métodos de solicitação HTTP
- HTTP GET com corpo da solicitação
A maioria das discussões parece concordar que fornecer um corpo de mensagem em um DELETE pode ser permitido , mas geralmente não é recomendado.
Além disso, notei uma tendência em várias bibliotecas de cliente HTTP, onde mais e mais melhorias parecem estar sendo registradas para essas bibliotecas para oferecer suporte a corpos de solicitação em DELETE. A maioria das bibliotecas parece obrigar, embora ocasionalmente com um pouco de resistência inicial.
Meu caso de uso exige a adição de alguns metadados necessários em um DELETE (por exemplo, o "motivo" da exclusão, junto com alguns outros metadados necessários para a exclusão). Considerei as seguintes opções, nenhuma das quais parece completamente apropriada e alinhada com as especificações HTTP e / ou práticas recomendadas REST:
- Corpo da mensagem - a especificação indica que os corpos da mensagem em DELETE não têm valor semântico; não é totalmente suportado por clientes HTTP; prática não padrão
- Cabeçalhos HTTP personalizados - exigir cabeçalhos personalizados é geralmente contra as práticas padrão ; usá-los é inconsistente com o resto da minha API, nenhum dos quais requer cabeçalhos personalizados; além disso, nenhuma boa resposta HTTP disponível para indicar valores de cabeçalho personalizados incorretos (provavelmente uma pergunta separada)
- Cabeçalhos HTTP padrão - Nenhum cabeçalho padrão é apropriado
- Parâmetros de consulta - Adicionar parâmetros de consulta realmente altera o URI de solicitação que está sendo excluído; contra as práticas padrão
- Método POST - (por exemplo
POST /resourceToDelete { deletemetadata }
) POST não é uma opção semântica para exclusão; O POST realmente representa a ação oposta desejada (ou seja, o POST cria subordinados de recursos, mas preciso excluir o recurso) - Métodos múltiplos - dividir a solicitação DELETE em duas operações (por exemplo, PUT excluir metadados e, em seguida, DELETE) divide uma operação atômica em duas, deixando potencialmente um estado inconsistente. O motivo da exclusão (e outros metadados relacionados) não fazem parte da representação do recurso em si.
Minha primeira preferência provavelmente seria usar o corpo da mensagem, em segundo lugar para cabeçalhos HTTP personalizados; no entanto, conforme indicado, existem algumas desvantagens para essas abordagens.
Existem recomendações ou melhores práticas em linha com os padrões REST / HTTP para incluir esses metadados necessários em solicitações DELETE? Existem outras alternativas que não considerei?
Jersey
não permitem corpo paradelete
solicitações.