Por que uma solicitação GET não deve alterar os dados no servidor?

Em toda a internet, vejo os seguintes conselhos:

Um GET nunca deve alterar dados no servidor - use uma solicitação POST para esse

Qual é a base para essa ideia?

Se eu faço um serviço php que insere dados no banco de dados e transmito parâmetros na string de consulta GET, por que isso está errado? (Estou usando instruções preparadas, para cuidar da injeção de SQL). Uma solicitação POST é de alguma forma mais segura?

Ou há alguma razão histórica para isso? Em caso afirmativo, qual é a validade deste conselho hoje?

Este não é um conselho.

A GETé definido dessa maneira no protocolo HTTP . É suposto ser idempotente e seguro .

Quanto ao porquê - a GETpode ser armazenado em cache e em um navegador, atualizado. De novo e de novo e de novo.

Isso significa que, se você fizer o mesmo GETnovamente, será inserido novamente no seu banco de dados .

Considere o que isso pode significar se ele se GETtornar um link e for rastreado por um mecanismo de pesquisa. Você terá seu banco de dados cheio de dados duplicados.

Sugiro também a leitura de URIs, endereçamento e o uso de HTTP GET e POST .

Há também um problema com a ligação prefetching em alguns navegadores - eles vão fazer uma chamada de pré-busca links, mesmo se não for indicada por isso, o autor da página.

Se, digamos, seu logout estiver protegido por um "GET", vinculado a todas as páginas do site, as pessoas poderão se desconectar apenas devido a esse comportamento.

Cada verbo HTTP tem sua própria responsabilidade. Por exemplo GET, conforme definido pela RFC

significa recuperar qualquer informação (na forma de uma entidade) identificada pelo Request-URI.

POST, por outro lado, significa inserir ou mais formalmente

O método POST é usado para solicitar que o servidor de origem aceite a
entidade incluída na solicitação como um novo subordinado do recurso
identificado pelo Request-URI na linha de solicitação

Razões para mantê-lo desta maneira:

• É muito simples e funciona na escala global da Internet desde 1991
• Atenha-se ao princípio da responsabilidade única
• Outras partes costumam GETatuar como meio de recuperação de informações e mineração de dados
• Presume-se que GET é uma operação segura que nunca modifica o estado do recurso
• Considerações de segurança, GETé efetivamente uma leitura , enquanto POSTé efetivamente uma gravação
• GET é armazenado em cache por navegadores, nós na rede, provedores de serviços de Internet
• A menos que o conteúdo seja alterado, GETo mesmo URL deve retornar os mesmos resultados para todos os usuários, caso contrário você não confiará mais no resultado retornado

Para garantir a integridade e apenas para impor o uso correto (origem) :

• GETos parâmetros são passados ​​como parte da URL, que possui um tamanho pequeno e limitado de 256 caracteres por padrão, com alguns servidores suportando mais de 4000 caracteres. Se você deseja inserir um registro longo, não há maneira legítima de transmitir esses dados em
• Ao usar conexão segura, ̶ como o TLS, ̶ URL é não conseguir criptografado, ̶, logo, todos os parâmetros do ̶ ̶G̶E̶T̶̶ são transferidos Texto simples. O URL é realmente criptografado com TLS, portanto, o TLS está correto.
• Inserir dados binários ou caracteres não ASCII usando GETé impraticável
• GET é reexecutado se um usuário pressionar um botão Voltar em um navegador
• Alguns rastreadores mais antigos podem não indexar URLs com um ?sinal dentro

EDIT: Antes, eu disse que o POST ajuda a protegê-lo contra o CSRF, mas isso está errado. Eu não pensei nisso corretamente. Você deve exigir um token oculto exclusivo do escopo da sessão em todas as suas solicitações para alterar os dados para se proteger contra o CSRF.

Nos primeiros dias da internet, havia aceleradores de navegador. Esses programas começariam a clicar nos links de uma página para armazenar em cache o conteúdo. O Google Web Accelerator foi um desses programas. Isso pode causar estragos em um aplicativo que faz alterações quando um link é clicado. Eu assumiria que ainda existem pessoas usando software acelerador.

Servidores e navegadores proxy armazenam em cache as solicitações GET, portanto, quando o usuário acessa a página novamente, ele pode não enviar a solicitação ao seu aplicativo, para que o usuário pense que tomou uma ação, mas na verdade não o fez.

Se eu faço um serviço php que insere dados no banco de dados e transmito parâmetros na string de consulta GET, por que isso está errado?

A resposta mais simples é "porque não é isso que GETsignifica".

Usar GETpara passar dados para uma atualização é como escrever uma carta de amor e enviá-la em um envelope marcado como "OFERTA ESPECIAL - Aja AGORA!" Nos dois casos, não se surpreenda que o destinatário e / ou os intermediários manuseiem incorretamente sua mensagem .

Para suas operações CRUD em um aplicativo centralizado em banco de dados, use o seguinte esquema:

Usar HTTP GET para operações de leitura (SQL SELECT)

Use HTTP PUT para operações de atualização (SQL UPDATE)

Usar HTTP POST para criar operações (SQL INSERT)

Use HTTP DELETE para operações de exclusão (SQL DELETE)

Um GET nunca deve alterar dados no servidor - use uma solicitação POST para esse

Esse conselho, e todas as respostas aqui estão erradas. Obviamente, estou sendo excessivamente dramático, as outras respostas são excelentes, mas acredito que o conselho exato deve ser dado como:

Um GET raramente deve alterar dados no servidor - use uma solicitação POST para esse

Dizer "nunca" é muito extremo e, embora as outras respostas aqui expliquem com precisão por que você "raramente" deve fazê-lo, há alguns cenários em que é perfeitamente razoável alterar dados com um GET. Um exemplo é um link de verificação de e-mail de uso único. Normalmente, esses links contêm um GUID que, quando acessado, terá que alterar dados. Se implementadas corretamente, solicitações GET idênticas subsequentes serão ignoradas.

Obviamente, este é um caso extremo, mas certamente vale a pena notar.