Por que não existem métodos PUT e DELETE nos formulários HTML?

HTML4 / XHTML1 permite apenas GET e POST nos formulários, agora parece que o HTML5 fará o mesmo. Há uma proposta para adicionar esses dois, mas não parece estar ganhando força. Quais foram os motivos técnicos ou políticos para não incluir PUT e DELETE no rascunho da especificação HTML5?

Esta é uma pergunta fascinante. As outras respostas aqui são todas especulativas e, em alguns casos, totalmente incorretas. Em vez de escrever minha opinião aqui, fiz algumas pesquisas e encontrei fontes originais que discutem por que excluir e colocar não fazem parte do padrão de formulário HTML5.

Acontece que esses métodos foram incluídos em vários rascunhos iniciais do HTML5 (!), Mas depois foram removidos nos rascunhos subsequentes . A Mozilla também implementou isso em uma versão beta do Firefox também.

Qual foi a justificativa para remover esses métodos do rascunho? O W3C discutiu esse tópico no relatório de bug 10671 . Mike Amundsen argumentou a favor desse apoio:

A execução de PUT e DELETE para modificar recursos no servidor de origem é simples para navegadores da Web modernos usando o objeto XmlHttpRequest. Para interações não programadas do navegador, isso não é tão simples. [...]

Esse padrão é necessário com tanta frequência que várias estruturas / bibliotecas da Web comumente usadas criaram uma solução alternativa "interna". [...]

Outras considerações:

• Usar o POST como um túnel em vez de usar PUT / DELETE pode levar a erros de correspondência de cache (por exemplo, as respostas POST são ajustáveis , as respostas PUT não são (6), as respostas DELETE não são (7))
• O uso de um método não idempotente (POST) para executar uma operação idempotente (PUT / DELETE) complica a recuperação devido a falhas na rede (por exemplo, "É seguro repetir esta ação?").
• [...]

Vale a pena ler o post inteiro.

Tom Wardrop também faz um ponto interessante:

O HTML está inextrincavelmente ligado ao HTTP. HTML é a interface humana do HTTP. Portanto, é automaticamente questionável por que o HTML não suporta todos os métodos relevantes na especificação HTTP. Por que as máquinas podem colocar e excluir recursos, mas os humanos não? [...]

É contraditório que, embora o HTML se esforce ao máximo para garantir a marcação semântica, até o momento não fez esse esforço para garantir solicitações HTTP semânticas.

O bug acabou sendo fechado como Won't Fix por Ian Hickson, com a seguinte lógica:

PUT como um método de formulário não faz sentido, você não deseja colocar uma carga útil de formulário. DELETE só faz sentido se não houver carga útil, portanto também não faz muito sentido nos formulários.

No entanto, esse não é o fim da história! O problema foi encerrado no rastreador de erros do W3C e encaminhado para o rastreador de problemas do HTML Working Group:

https://www.w3.org/html/wg/tracker/issues/195

Neste ponto, parece que a principal razão pela qual não há suporte para esses métodos é simplesmente porque ninguém gastou tempo para escrever uma especificação abrangente para ele.

GET e POST têm uma lógica clara de neutralidade de conteúdo. GET é recuperar o conteúdo de um URL de uma maneira segura para repetir e possivelmente armazenar em cache. O POST é fazer algo de maneira que não seja seguro repetir, executar especulativamente ou armazenar em cache.

Não havia lógica semelhante para PUT ou DELETE. Ambos são completamente cobertos pelo POST. Criar ou destruir um recurso são operações que não são seguras para serem repetidas, não são seguras para serem executadas especulativamente e não devem ser armazenadas em cache. Não há semântica especial adicional necessária para eles.

Então, basicamente, não há benefício.

Isso foi levantado em 2010, pois o Bug 10671 considera adicionar suporte para PUT e DELETE como métodos de formulário .

Houve uma quantidade moderada de pushback para esse "recurso" e alguma mão pesada, mas, eventualmente, isso foi escalado como dois problemas no rastreador de erros dos Grupos de Trabalho:

• ISSUE-195: Aprimore a geração de solicitações http a partir de formulários
• ISSUE-196: Definir o comportamento de manipulação de resposta http do agente do usuário

O problema ISSUE-196 resultou em uma decisão de consenso de não executar nenhuma alteração na especificação, pois a especificação HTML atualmente não restringe como as respostas às solicitações POST são tratadas. Acredito que esse problema específico foi levantado na tentativa de reconciliar os padrões de redirecionamento do POST comumente usados ​​e como os servidores ReSTful geralmente fornecem respostas 2xx com mensagens curtas, em vez de algo útil para ser renderizado em um navegador.

A edição ISSUE-195 foi apresentada às presidentes. Cameron Jones se apresentou como voluntário ao escrever uma proposta de mudança em 18 de janeiro de 2012, que ele enviou para se tornar o primeiro rascunho de trabalho em 29 de maio de 2014. O rascunho passará pelo processo de recomendações do W3C .

Com alguma sorte, isso em breve se tornará uma recomendação do W3C e implementada pelos fornecedores de navegadores, e seria um grande passo à frente na remoção dos bloqueadores para produzir serviços ReSTful unificados, semânticos e amigáveis ​​ao navegador. Eu imagino que isso desencadeie uma evolução interessante nos padrões de serviço. Há uma boa conversa de Jon Moore - APIs de hipermídia que vale a pena assistir, isso despertou meu interesse, mas caiu no primeiro obstáculo (este).

Meu entendimento é que os navegadores não sabem o que fazer quando enviam um PUT ou DELETE. Um POST será redirecionado para uma página apropriada normalmente, mas PUT e DELETE normalmente não. Isso os torna apropriados para chamadas via ajax ou um programa nativo, mas não a partir de um formulário do navegador da web.

Não posso impedi-lo agora, mas lembro de ler uma das listas de discussão html5 quando eles estavam discutindo isso.

História

Acho que vale a pena mencionar a primeira aparição de formulários html no RFC1866 (Seção 8.1) . Aqui, o atributo do método é definido da seguinte maneira:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Explicações adicionais estão localizadas na Seção 8.2.2 - GET e Seção 8.2.3 - POST

Lembre-se de que o HTML 2.0 (novembro de 1995) foi especificado antes do HTTP 1.0 (maio de 1996). Então, todo mundo usou HTTP apenas com GET (a partir de HTTP 0.9) ou com a extensão POST. Mas apenas alguns servidores da web suportam PUT e DELETE (como indicado no Apêndice HTTP 1.0 ).

Pensamentos

Se você pensar em como o desenvolvimento da rede semântica por Berners-Lee poderia ter evoluído, parece claro que passou de problemas reais para um conceito geral. Primeiro ele queria compartilhar documentos. Portanto, ele precisava de marcação. Então ele queria consultar os bancos de dados em busca de conteúdo, então precisava de formulários. Então ele quis colocar novos dados no banco de dados. Então ele usou formulários com GET e POST. Depois disso, ele pode ter percebido que era possível executar todas as operações CRUD nos dados remotos, portanto o HTTP foi estendido, mas nunca o HTML, porque era tarde demais (apenas alguns servidores suportavam as novas operações CRUD).

Apenas dando um palpite, mas provavelmente porque o HTTP não é muito bom com controle de acesso na melhor das hipóteses, e a última coisa que todo mundo precisa é de ainda mais maneiras de URLs maliciosos comprometerem um site e / ou aplicativo mal protegido.

O HTTP não é realmente um bom protocolo para transferências de arquivos que não seja o download do servidor para o cliente. Use FTP - ou melhor ainda, SFTP.

Get e post são formatos de transmissão dos dados da solicitação.

Suponho que você esteja perguntando sobre como fazer o envio de formulários em um serviço RESTFUL. Mas não faz sentido alterar o padrão de solicitação http para fazer das suposições o objetivo da solicitação http. As informações sobre a finalidade que a solicitação preenche são melhor tratadas nos campos de entrada.

Ter um endereço e obter e publicar permite que o servidor interprete a solicitação e seus valores de entrada corretamente. A partir daí, os valores de entrada permitem que você faça solicitações abertas ao servidor e faça o que quiser. Por exemplo, você pode ter um campo cujos valores são "colocar" e "excluir"