Métodos HTTP - GET VS POST | W3Docs

HTTP (Protocolo de Transferencia de Hipertexto) fue creado para proporcionar comunicación entre clientes y un servidor. Funciona con un modelo de solicitud-respuesta: el cliente envía una solicitud que especifica un método HTTP (también llamado verbo HTTP), y el método le indica al servidor qué tipo de acción realizar sobre el recurso objetivo.

Un <form> HTML admite de forma nativa solo dos de estos métodos — GET y POST — a través de su atributo method. Por eso estos dos son los que la mayoría de los desarrolladores HTML encuentran primero. Sin embargo, HTTP en sí define varios métodos más (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), a los que se accede mediante JavaScript (fetch) o desde el backend al construir APIs REST.

Dos propiedades clave: seguro e idempotente

Antes de ver los métodos individuales, hay dos términos que describen cómo se comporta cada uno. Se utilizan a lo largo de esta página y en las especificaciones HTTP.

Seguro — el método es de solo lectura. No debe cambiar el estado del servidor. Obtener una página nunca debería crear, actualizar ni eliminar nada. GET, HEAD y OPTIONS son seguros.
Idempotente — realizar la misma solicitud una o varias veces tiene el mismo efecto en el servidor. Enviar un DELETE para un recurso una vez, o enviarlo cinco veces, deja el recurso eliminado en ambos casos. Los métodos seguros son siempre idempotentes, pero un método puede ser idempotente sin ser seguro (por ejemplo, PUT y DELETE).

Aquí se comparan los métodos más comunes:

Método	Seguro	Idempotente	Tiene cuerpo de solicitud	Uso típico
GET	Sí	Sí	No	Recuperar un recurso
HEAD	Sí	Sí	No	Recuperar solo las cabeceras
OPTIONS	Sí	Sí	No	Descubrir métodos permitidos / preflight CORS
POST	No	No	Sí	Crear un recurso o enviar datos
PUT	No	Sí	Sí	Reemplazar / actualizar un recurso en una URL conocida
PATCH	No	No garantizado	Sí	Aplicar una modificación parcial
DELETE	No	Sí	Generalmente no	Eliminar un recurso

Información

PATCH no garantiza ser idempotente. Dependiendo de cómo esté escrito el parche, puede serlo (por ejemplo, "establecer status en active") o no (por ejemplo, "incrementar el contador en 1"). La especificación HTTP deja esto a la implementación.

Método GET

El método GET solicita datos de una fuente especificada. Es seguro e idempotente: solo lee datos y nunca modifica nada en el servidor. Las solicitudes GET pueden almacenarse en caché y quedan en el historial del navegador. También pueden marcarse como favoritos.

Nunca debe usarse para datos sensibles, ya que la cadena de consulta forma parte de la URL (que se registra, almacena en caché y se guarda como favorito). Las solicitudes GET tienen restricciones prácticas de longitud y deben usarse únicamente para recuperar datos.

Peligro

Las cadenas de consulta (pares nombre/valor) se envían en la URL de la solicitud GET.

Ejemplo de un campo de texto con el método get

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Pruébalo tú mismo »

Método POST

El método POST envía datos para ser procesados a una fuente especificada. No es ni seguro ni idempotente: puede cambiar el estado del servidor, y enviar el mismo formulario dos veces generalmente crea dos registros — por eso los navegadores te advierten antes de reenviar datos POST. A diferencia del método GET, las solicitudes POST nunca se almacenan en caché, no quedan en el historial del navegador y no pueden marcarse como favoritos. Además, las solicitudes POST no están sujetas a restricciones de longitud de URL, aunque los servidores normalmente imponen sus propios límites de tamaño de cuerpo.

Peligro

Las cadenas de consulta (pares nombre/valor) se envían en el cuerpo del mensaje HTTP de la solicitud POST.

Ejemplo de un formulario con el método "post"

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Pruébalo tú mismo »

Comparación de los métodos GET y POST

Característica	GET	POST
Botón Atrás/Recargar	Sin consecuencias	Al recargar la página se reenviarán los datos del formulario. El navegador debe advertir que los datos se reenviarán en este caso.
Se puede marcar como favorito	Sí	No
Se puede almacenar en caché	Sí	No
Tipo de codificación	application/x-www-form-urlencoded	application/x-www-form-urlencoded o multipart/form-data
Historial	Permanece en el historial del navegador.	No permanece en el historial del navegador.
Restricciones de longitud de datos	Al enviar datos, el método GET los añade a la URL. La longitud de la URL es limitada (longitud máxima: 2048 caracteres).	No tiene restricciones de longitud de URL, aunque los servidores normalmente imponen límites de tamaño de cuerpo.
Restricción de tipo de datos	Principalmente caracteres ASCII, aunque UTF-8 es compatible mediante codificación porcentual.	No tiene restricciones. Los datos binarios también están permitidos.
Seguridad	Menos seguro que POST, ya que los datos enviados forman parte de la URL.	POST es más seguro que GET, ya que los datos no son visibles en la URL ni en el historial del navegador. Sin embargo, ambos transmiten datos en texto plano sobre HTTP y requieren HTTPS para una seguridad real.
Visibilidad	Los datos son visibles para todos en la URL.	No muestra los datos en la URL.

Nota El elemento <form> HTML admite de forma nativa solo GET y POST a través de su atributo method. Para usar PUT, PATCH o DELETE, normalmente se envía la solicitud con JavaScript (fetch) o se deja que el framework del backend sobrescriba el método.

HEAD, OPTIONS y CONNECT

Además de GET y POST, HTTP define varios otros métodos. Tres de ellos se describen aquí; los métodos orientados a recursos PUT, PATCH y DELETE se tratan en sus propias secciones.

Método	Seguro	Idempotente	Descripción
HEAD	Sí	Sí	Idéntico a GET, pero el servidor devuelve solo las cabeceras HTTP, no el cuerpo de la respuesta.
OPTIONS	Sí	Sí	Pregunta al servidor qué métodos y opciones están disponibles para un recurso.
CONNECT	No	No	Establece un túnel hacia el servidor, utilizado por proxies para HTTPS.

HEAD

HEAD funciona exactamente igual que GET, pero el servidor omite el cuerpo y devuelve solo las cabeceras. Dado que es seguro e idempotente, es ideal cuando se necesitan metadatos sin descargar todo el recurso — por ejemplo, comprobar el Content-Length de un archivo grande antes de descargarlo, o verificar si una URL sigue siendo accesible (su código de estado) sin transferir su contenido.

OPTIONS

OPTIONS pregunta al servidor qué permite para un recurso. La respuesta normalmente incluye una cabecera Allow con la lista de métodos admitidos (por ejemplo, Allow: GET, POST, OPTIONS). Su uso más importante en la práctica es la solicitud preflight de CORS: antes de que un navegador envíe un PUT, DELETE entre orígenes, o una solicitud con cabeceras personalizadas, dispara automáticamente una solicitud OPTIONS para confirmar que el servidor permite la llamada real. Rara vez se escriben solicitudes OPTIONS a mano — el navegador lo hace por ti.

CONNECT

CONNECT le indica a un servidor proxy que establezca un túnel TCP/IP transparente hacia el destino, generalmente para que el tráfico HTTPS cifrado pueda pasar a través del proxy sin ser leído. Es utilizado por la infraestructura en lugar del código de aplicación, por lo que casi nunca se llama directamente.

Método PUT

El método PUT se usa principalmente para reemplazar o actualizar un recurso. El cliente envía la URL del recurso objetivo junto con un cuerpo de solicitud que contiene la representación completa y actualizada de ese recurso. PUT también puede crear un recurso cuando es el cliente (y no el servidor) quien decide la URL del recurso.

PUT no es seguro, porque cambia el estado en el servidor, pero es idempotente: si envías la misma solicitud PUT dos veces, el recurso termina en exactamente el mismo estado que tras una sola solicitud — el cuerpo reemplaza por completo lo que hubiera antes.

El ejemplo siguiente le pide al servidor que almacene el cuerpo JSON dado como el recurso en /users/42:

Métodos HTTP - ejemplo de solicitud PUT

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Tras almacenar el cuerpo, el servidor podría responder así:

Métodos HTTP - ejemplo de respuesta PUT

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Método PATCH

El método PATCH se usa para la modificación parcial de un recurso. A diferencia de PUT, no necesita el recurso completo — el cuerpo contiene solo los cambios a aplicar.

PATCH no es seguro y no garantiza ser idempotente: dependiendo del formato del parche, puede producir o no el mismo resultado cuando se repite. Un parche como "establecer status en active" es idempotente, pero uno como "sumar 1 a views" no lo es. Las colisiones entre dos solicitudes PATCH también pueden ser peligrosas, porque algunos formatos de parche esperan aplicar cambios desde un estado base compartido; de lo contrario, el recurso puede corromperse.

El ejemplo siguiente cambia únicamente el campo email del usuario, dejando todos los demás campos intactos:

Métodos HTTP - ejemplo de solicitud PATCH

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

Método DELETE

Como su nombre indica, este método elimina el recurso identificado por una URL. DELETE no es seguro pero es idempotente: una vez que un recurso se elimina, volver a llamar a DELETE lo deja eliminado — el estado final es el mismo. (Las llamadas repetidas pueden devolver un código de estado diferente, como 404 Not Found en el segundo intento, pero el estado del servidor no cambia más.)

El ejemplo siguiente le pide al servidor que elimine el usuario en /users/42:

Ejemplo de solicitud DELETE

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

Tras eliminar el recurso, el servidor responde habitualmente con 204 No Content — un estado de éxito que no lleva cuerpo de respuesta:

Ejemplo de respuesta DELETE

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Una respuesta 200 OK (opcionalmente con un cuerpo que describe el recurso eliminado) también es una respuesta DELETE válida. Consulta mensajes de estado HTTP para ver la lista completa de códigos de estado.