Métodos de envío

¿Qué pasa cuando se aprieta el botón?

El navegador arma un mensaje —una petición— y lo manda al servidor. Ese mensaje tiene tres partes que importan, y las tres se definen en el formulario:

• El método: qué se quiere hacer. Lo decide method.
• La dirección: a quién se le pide. La decide action.
• El contenido: los datos que se escribieron, con sus name.

Los dos métodos que usan los formularios son GET y POST. Su diferencia principal es una sola, y conviene decirla de entrada porque explica todo lo demás: dónde viajan los datos.

En los dos casos el dato llega igual al servidor. Ninguno es más moderno ni más seguro que el otro por sí mismo. Lo que cambia es dónde va y, como consecuencia, quién lo puede ver. Elegir mal no rompe el formulario: lo hace funcionar de una manera que trae problemas.

GET: los datos en la dirección

Con GET, los datos se pegan al final de la dirección, después de un signo de pregunta. El formato es siempre el mismo:

/buscar?apellido=perez&curso=5to
        └─┬─┘ │     └─┬─┘ │   └─┬─┘
          ?   clave   =   &  otra clave

El ? separa la dirección de los datos, el = une cada clave con su valor y el & une un dato con el siguiente. Esa parte se llama cadena de consulta.

Que los datos estén a la vista tiene consecuencias en las dos direcciones. Como ventajas:

• Se puede guardar en favoritos. Un listado filtrado por curso queda como un enlace que se puede volver a abrir tal cual.
• Se puede compartir. Mandar por mensaje la dirección de una búsqueda es mandar la búsqueda.
• Recargar no molesta. Apretar F5 repite la consulta sin preguntar nada.

Y como desventajas, que son las que hay que tener presentes:

• Queda registrado en todos lados: en el historial del navegador, en los logs del servidor —que suelen guardar la dirección completa de cada visita— y en el historial de cualquier equipo intermedio.
• Tiene un límite de largo. Las direcciones muy largas se cortan, en el orden de los 2000 caracteres según el navegador y el servidor. No sirve para un comentario extenso ni, mucho menos, para un archivo.
• Se puede repetir sin querer. Un enlace con datos dentro puede ser visitado por cualquiera, incluidos los programas que recorren los sitios automáticamente.

POST: los datos en el cuerpo

Con POST, los datos no van en la dirección. Van en el cuerpo del mensaje, que es una parte separada de la petición y que la barra de direcciones no muestra. La dirección queda limpia: solo el destino.

• No se ven en la barra de direcciones.
• No quedan en el historial ni se pueden guardar en favoritos.
• No tienen límite práctico de tamaño: es lo que permite mandar una observación larga o un archivo.
• Recargar avisa. Si después de enviar se aprieta F5, el navegador pregunta si se quieren reenviar los datos. Ese cartel molesto es la señal de que se está usando POST, y existe justamente porque el reenvío podría duplicar el dato.

Los dos, lado a lado

Dos de esas filas son las que deciden, y las dos apuntan al mismo lugar: GET se puede repetir sin consecuencias y sirve para consultar; POST no se puede repetir sin consecuencias y sirve para modificar. Todo lo demás son detalles que se desprenden de eso.

Ver lo que efectivamente viaja

Cuando un dato no llega a la base de datos, el primer paso no es mirar el SQL: es comprobar que salió del formulario. Y eso se puede ver.

• Con GET, no hace falta nada: se mira la barra de direcciones. Si el dato no está ahí, no se está enviando.
• Con POST hay que abrir las herramientas de desarrollo del navegador con F12, ir a la pestaña de Red, enviar el formulario y buscar la petición. Ahí aparecen la dirección, el método y —en la pestaña de la solicitud— la lista de pares name = valor que salieron.

Vale la pena hacerlo al menos una vez, aunque todo funcione. Ver la lista real de datos que salieron del formulario explica de golpe todo lo que se vio en las páginas anteriores: por qué sin name el campo no aparece, por qué una casilla sin marcar no figura, y por qué un <select> manda el código que está en el value y no el texto que se lee en pantalla.

Cuál usar

La regla se enuncia en seis palabras: GET para pedir, POST para cambiar.

La razón de fondo no es estética, y vale la pena entenderla porque es la que evita desastres. GET es seguro e idempotente: repetirlo diez veces deja todo igual que repetirlo una. POST, no: cada envío puede agregar una fila nueva.

Y eso tiene una consecuencia concreta que pasó de verdad en la web temprana. Los buscadores recorrían los sitios siguiendo todos sus enlaces para indexarlos. En los sitios donde las acciones estaban mal armadas como enlaces GET —/productos/borrar?id=7— ese recorrido automático borraba los productos. Nadie apretó ningún botón: el buscador los visitó uno por uno creyendo que eran páginas para leer.

Por eso la regla se sostiene en algo más que una convención. Una acción que modifica datos nunca debería poder dispararse con solo visitar una dirección: si se puede, tarde o temprano algo la va a visitar sola. Y hay un segundo motivo, más cercano: un enlace con la acción adentro se puede mandarle a otra persona para que la ejecute sin darse cuenta.

Lo que nunca va por GET

Con GET, todo lo que se escribe queda escrito en la barra de direcciones. Y lo que está en la barra de direcciones queda, además, en el historial del navegador, en los registros del servidor, en cualquier equipo intermedio de la red, y en la primera foto o video de pantalla que alguien comparta.

Alcanza con imaginar un formulario de acceso mal armado. Alguien entra desde una computadora compartida y la dirección queda así en el historial:

/ingreso?usuario=mauro&clave=MiClave123
                              └──────────┘
                         esto queda registrado, en texto plano

Resumen

• El atributo method del formulario decide dónde viajan los datos: en la dirección o en el cuerpo del mensaje.
• Con GET, los datos se pegan después de un ?, con pares clave=valor unidos por &.
• Con POST, la dirección queda limpia y los datos viajan aparte, sin límite práctico de tamaño.
• En los dos casos el dato llega igual: ninguno es «mejor» en abstracto.
• GET deja rastro en el historial y en los logs, y se puede guardar y compartir.
• POST no cifra nada: para eso está HTTPS.
• La regla: GET para pedir, POST para cambiar.
• Una acción que modifica datos nunca se dispara con solo visitar una dirección.
• Las contraseñas y los datos personales van siempre por POST.

Ver la inserción de datos