¿Cuáles son las principales diferencias entre los métodos de solicitud HTTP GET y POST?

Propósito

• GET solicita una representación de un recurso. Por especificación es de solo lectura: el cliente no espera ningún cambio en el estado del servidor. La RFC 9110 señala que enviar un cuerpo en una solicitud GET tiene semántica indefinida, por lo que GET no debe llevar cuerpo.
• POST pide al recurso de destino que procese los datos incluidos en el cuerpo de la solicitud según la semántica de ese recurso (crear un registro, enviar un formulario, subir un archivo, etc.).

Dónde van los datos

• GET lleva parámetros en la cadena de consulta de la URL (después de ?, con formato key=value&...). Estos son visibles en la barra de direcciones y quedan registrados en el historial del navegador y en los registros del servidor, y están limitados por una restricción práctica de longitud de la URL.
• POST lleva datos en el cuerpo de la solicitud; el tipo se indica mediante el encabezado Content-Type. Los formularios HTML suelen usar application/x-www-form-urlencoded (el valor predeterminado) o multipart/form-data (para archivos). No existe un límite fijo a nivel de protocolo, pero los servidores y proxies configuran sus propios máximos (por ejemplo, Nginx client_max_body_size).

Propiedades según la RFC 9110

• Seguro: GET es seguro (solo lectura); POST no lo es.
• Idempotente: una solicitud es idempotente si hacerla N veces tiene el mismo efecto en el estado del servidor que hacerla una vez. GET es idempotente; POST no lo es: repetirla puede crear duplicados, como dos pedidos idénticos. Idempotente no es lo mismo que seguro (PUT y DELETE son idempotentes pero no seguros), y no dice nada sobre que el cuerpo de la respuesta sea idéntico.
• Cacheable: las respuestas GET son cacheables por defecto; las respuestas POST solo son cacheables cuando incluyen información explícita de frescura y un encabezado Content-Location coincidente, lo cual es raro en la práctica.

Implicaciones prácticas

• Usa GET para recuperación y navegación; los resultados pueden repetirse, marcarse como favoritos y precargarse con seguridad, y actualizar una página GET no causa daño.
• Usa POST para acciones que cambian el estado y para enviar cargas sensibles o grandes. Actualizar o volver atrás en una página POST activa la advertencia del navegador "confirmar reenvío del formulario".
• Nunca envíes contraseñas mediante GET — terminarían en la URL, los registros y el historial. Esto es higiene, no cifrado: HTTPS cifra tanto la URL como el cuerpo en tránsito, pero la URL sigue registrándose.

Seguimientos comunes

• Los métodos seguros son GET, HEAD, OPTIONS; los idempotentes son GET, HEAD, PUT, DELETE; POST no es ninguno de los dos.
• Ambos métodos son compatibles con formularios HTML (el atributo method).
• "Seguro" en el sentido de la RFC significa ausencia de cambio de estado, no protección de datos.
• La idempotencia de POST a nivel de aplicación suele imponerse mediante claves de idempotencia.