¿Por qué una solicitud GET no debe cambiar los datos en el servidor?

Esto no es un consejo.

Un GET se define de esta manera en el protocolo HTTP . Se supone que es idempotent y safe .

En cuanto a por qué: un GET se puede almacenar en caché y actualizar en un navegador. Una y otra y otra vez.

Esto significa que si vuelve a hacer el mismo GET , lo insertará en su base de datos de nuevo .

Considere lo que esto puede significar si el GET se convierte en un enlace y un motor de búsqueda lo rastrea. Tendrás tu base de datos llena de datos duplicados.

También sugiero leer URI, direccionabilidad y el uso de HTTP GET y POST .

También hay un problema con búsqueda previa de enlaces en algunos navegadores: realizarán una llamada a los enlaces de búsqueda previa, incluso si no lo indica el autor de la página.

Si, digamos, su cierre de sesión está detrás de un "GET", vinculado desde cada página de su sitio, las personas pueden cerrar su sesión solo debido a este comportamiento.

Cada verbo HTTP tiene su propia responsabilidad. Por ejemplo, GET , como se define en RFC

  

significa recuperar cualquier información (en forma de una entidad) identificada por el URI de solicitud.

POST , por otro lado, significa insertar o más formalmente

  

El método POST se utiliza para solicitar que el servidor de origen acepte el
  Entidad incluida en la solicitud como un nuevo subordinado del recurso
  identificado por el URI de solicitud en la línea de solicitud

Razones para mantenerlo de esta manera:

• Es muy simple y funciona en la escala global de Internet desde 1991
• Se adhieren al principio de responsabilidad única
• Otras partes usan GET para actuar como medio de recuperación de información y extracción de datos
• Se supone que GET es una operación segura que nunca modifica el estado del recurso
• Consideraciones de seguridad, GET es efectivamente una lectura , mientras que POST es efectivamente una escritura
• GET se almacena en caché por los navegadores, los nodos de la red, los proveedores de servicios de Internet
• A menos que el contenido cambie, GET a la misma URL debe devolver los mismos resultados a todos los usuarios o, de lo contrario, no tendrá ninguna confianza en el resultado devuelto

Para completar y solo para hacer cumplir el uso correcto (source) :

• Los parámetros GET se pasan como parte de la URL, que tiene una longitud limitada y pequeña de 256 caracteres de forma predeterminada, y algunos servidores son compatibles con más de 4000 caracteres. Si desea insertar un registro largo, no hay una manera legítima de pasar estos datos
• Cuando se utiliza Conexión segura, ̶ tales como TLS, ̶ URL es no conseguir cifrado, ̶ por lo tanto, todos los parámetros de ̶ ̶G̶E̶T̶ ̶ se transfieren texto sin formato. La URL está encriptada con TLS, por lo que TLS está bien.
• Insertar datos binarios o caracteres no ASCII utilizando GET no es práctico
• GET se vuelve a ejecutar si un usuario presiona el botón Atrás en un navegador
• Es posible que algunos rastreadores más antiguos no indexen las URL con un signo ? dentro

EDITAR: Antes, dije que POST te ayuda a protegerte contra CSRF pero esto está mal. No lo pensé correctamente. Debe requerir un token oculto único de alcance de sesión en todas sus solicitudes para cambiar los datos para proteger contra CSRF.

En los primeros días de internet había aceleradores de navegador. Estos programas comenzarían a hacer clic en los enlaces de una página para almacenar en caché el contenido. Google Web Accelerator fue uno de estos programas. Esto podría causar estragos en una aplicación que realiza cambios cuando se hace clic en un enlace. Supongo que todavía hay personas que usan software acelerador.

Los servidores y navegadores proxy almacenarán en caché las solicitudes GET, de modo que cuando el usuario acceda a la página nuevamente, es posible que no envíe la solicitud a su aplicación, por lo que el usuario cree que tomó una acción, pero realmente no lo hizo.

  

Si hago un servicio php que inserta datos en la base de datos, y paso   los parámetros en la cadena de consulta GET, ¿por qué está mal?

La respuesta más simple es "porque eso no es lo que significa GET ".

Usar GET para pasar datos para una actualización es como escribir una carta de amor y enviarla en un sobre marcado "¡OFERTA ESPECIAL - ACTÚE AHORA!" En ambos casos, no debe sorprenderse de que el destinatario y / o los intermediarios manejen mal su mensaje .

Para sus CRUD en una aplicación centrada en la base de datos, utilice el siguiente esquema:

Utilice HTTP GET para operaciones de lectura (SQL SELECT)

Use HTTP PUT para las operaciones de actualización (ACTUALIZACIÓN DE SQL)

Use HTTP POST para crear operaciones (SQL INSERT)

Use HTTP DELETE para eliminar operaciones (SQL DELETE)

  

Un GET nunca debe cambiar los datos en el servidor; use una solicitud POST para   que

Ese consejo, y todas las respuestas aquí son incorrectas. Obviamente estoy siendo demasiado dramático, las otras respuestas son excelentes, pero creo que el consejo exacto debe darse como:

  

Un GET debería rara vez cambiar los datos en el servidor; use una solicitud POST para   que

Decir "nunca" es demasiado extremo, y aunque las otras respuestas aquí explican con precisión por qué debería hacerlo "rara vez", hay algunos escenarios donde es perfectamente razonable cambiar los datos con un GET. Un ejemplo es un enlace de verificación de correo electrónico de un solo uso. Normalmente, estos enlaces contienen un GUID que, cuando se accede, tendrá que cambiar los datos. Si se implementan correctamente, se ignorarán las solicitudes GET idénticas subsiguientes.

Este es obviamente un caso de ventaja, pero ciertamente vale la pena señalarlo.