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

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

Não havia justificativa 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 repetir, não são seguras para executar especulativamente e não devem ser armazenadas em cache. Não há nenhuma semântica especial adicional necessária para eles.

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

Isto foi levantado em 2010 como Bug 10671 considere adicionar suporte para PUT e DELETE como métodos de formulário .

Houve uma quantidade moderada de retrocessos para esse "recurso" e algumas dificuldades, mas no final isso foi escalado como dois problemas no rastreador de bugs dos grupos de trabalho:

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

O problema ISSUE-196 resultou em uma decisão de consenso de não realizar nenhuma alteração na especificação como a especificação HTML não restringe atualmente 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 de POST normalmente em uso e como os servidores ReSTful geralmente fornecem respostas 2xx com mensagens curtas, em vez de algo útil para ser renderizado em um navegador.

O problema ISSUE-195 foi apresentado aos presidentes. Cameron Jones se apresentou como voluntário ao escrever uma proposta de mudança em 18 de janeiro de 2012, a qual ele submeteu para tornar-se 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 logo se tornará uma recomendação do W3C e implementada por fornecedores de navegadores, e seria um grande passo em frente na remoção dos bloqueadores para produzir serviços ReSTful unificados, semânticos e amigáveis ao navegador. Eu imagino que isto irá desencadear uma evolução interessante nos padrões de serviço. Há uma boa conversa por Jon Moore - APIs da Hipermídia que vale a pena assistir, isso me interessou, mas caiu no primeiro obstáculo (este aqui).

Meu entendimento é que os navegadores não sabem o que fazer quando enviam um PUT ou um DELETE. Um POST redirecionará 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 de um formulário de navegador da Web.

Eu não posso atrasá-lo agora, mas lembro-me de ler uma das listas de discussão do html5 quando eles estavam discutindo isso.

História

Acho que vale a pena mencionar a primeira aparição de formulários html na RFC1866 (Seção 8.1) . Aqui, o atributo method é definido da seguinte forma:

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".

Outras explicações estão localizadas na Seção 8.2.2 - GET e Section 8.2.3 - POST

Tenha em mente que o HTML 2.0 (novembro de 1995) foi especificado antes HTTP 1.0 (Maio de 1996). Então todo mundo usou HTTP apenas com GET (como de HTTP 0.9) ou com a extensão POST. Mas apenas alguns servidores da web suportavam PUT e DELETE (como declarado no Apêndice HTTP 1.0 ).

Pensamentos

Se você pensar em como o desenvolvimento da web semântica de 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 bancos de dados para conteúdo, então ele precisava de formulários. Então ele queria colocar novos dados no banco de dados. Então, ele usou formulários com GET e POST. Depois disso, ele pode ter percebido que você poderia fazer cada operação CRUD em dados remotos, então o HTTP foi estendido, mas nunca HTML, porque era tarde demais (apenas alguns servidores suportavam as novas operações CRUD).

Apenas estou tentando adivinhar, mas provavelmente porque o HTTP não é muito bom com controle de acesso no melhor dos casos, e a última coisa que todo mundo precisa é de mais formas de fazer com que URLs mal-intencionados comprometam um site e / ou aplicativo mal protegido.

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

Obter e postar são formatos de transmissão dos dados da solicitação.

Suponho que você esteja perguntando sobre como fazer a submissão do formulário em um serviço RESTFUL. Mas não faz sentido alterar o padrão de solicitação http para fazer suposições a finalidade da solicitação http. Informações sobre o propósito que a solicitação preenche são melhor tratadas nos campos de entrada.

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