Petición HTTP: cómo funciona, métodos y estructura

¿Qué es una petición HTTP?

Una petición HTTP es la forma en que un cliente (normalmente un navegador o una aplicación) se dirige a un servidor web para interactuar con recursos en línea. Puede pedir ver una página web, enviar los datos de un formulario o modificar datos almacenados. Cada petición HTTP utiliza protocolos HTTP y un método definido (GET, POST, PUT, DELETE) que indica al servidor qué debe hacer.

Algunos desarrolladores utilizan operaciones PUT para modificar entradas existentes, y DELETE se aplica habitualmente para eliminar las obsoletas.

¿Cómo funciona una petición HTTP?

Al abrir un sitio web o pulsar un botón, su dispositivo suele crear una petición que se envía a un servidor. El mensaje que envía contiene cabeceras (sobre el tipo de navegador, el idioma, etc.) y puede incluir un cuerpo de mensaje con campos como el nombre de usuario y la contraseña durante el inicio de sesión o el registro. Las cabeceras también definen los tipos de contenido aceptados, lo que ayuda a los servidores a entregar formatos adecuados como JSON, XML o HTML

El servidor procesa la información y responde con lo que se conoce como respuesta. Esta puede incluir un código de estado, un breve mensaje de estado (como «OK» o «Not Found») y, posiblemente, el contenido solicitado. Estas respuestas del servidor ayudan al navegador o a la aplicación a decidir qué mostrar o qué hacer a continuación.

El recorrido completo, desde el clic hasta el contenido, suele desarrollarse en cuatro pasos. Primero, el navegador resuelve el nombre de dominio en una dirección IP mediante DNS. A continuación, abre una conexión TCP con esa dirección y envía por ella la petición HTTP. Después, el servidor lee la petición, busca el recurso y construye una respuesta. Por último, la respuesta viaja de vuelta por la misma conexión y el navegador renderiza la página o entrega los datos a la aplicación.

Cada uno de estos pasos solo tarda milisegundos, pero se repiten en cada carga de página, cada imagen y cada llamada a la API que hace su dispositivo. Servidores web muy conocidos como Apache y Nginx están diseñados para gestionar con fluidez un gran volumen de estas interacciones, tanto si sirven HTML como datos dinámicos.

Estructura de una petición HTTP

Toda petición HTTP sigue la misma estructura de tres partes, sea cual sea el método que utilice o los datos que transporte.

• Línea de petición. La primera línea indica al servidor qué debe hacer. Contiene el método (GET, POST, etc.), la ruta del recurso solicitado y la versión del protocolo — por ejemplo, GET /pricing HTTP/1.1.

• Cabeceras. Son pares clave-valor que describen la petición. La cabecera Host indica al servidor a qué sitio pertenece la petición. User-Agent identifica el navegador o la aplicación que la envía. Accept declara qué tipos de contenido puede leer el cliente. Authorization transporta las credenciales cuando el recurso está protegido.

• Cuerpo (opcional). No todas las peticiones tienen cuerpo. GET y DELETE normalmente no lo tienen. POST, PUT y PATCH suelen tenerlo — es aquí donde los datos de formularios, las cargas útiles JSON o los archivos subidos viajan del cliente al servidor.

Una petición GET simple en bruto tiene este aspecto:

GET /glossary/http-request HTTP/1.1
Host: proxywing.com
User-Agent: Mozilla/5.0
Accept: text/html

Métodos de petición HTTP

El método indica al servidor qué tipo de acción quiere el cliente. La mayor parte del tráfico web utiliza solo dos — GET y POST —, pero el conjunto completo cubre todas las operaciones habituales que una aplicación pueda necesitar.

• GET: obtiene datos sin cambiar nada en el servidor. Cargar una página web, una imagen o un resultado de la API es casi siempre un GET.
• POST: envía datos al servidor, normalmente para crear algo nuevo. Enviar un formulario, subir un archivo o registrar una cuenta entra aquí.
• PUT: sustituye un recurso existente por los datos nuevos enviados en el cuerpo. Se utiliza cuando el cliente sabe exactamente cómo debe quedar el recurso.
• PATCH: actualiza solo los campos que deben cambiar, en lugar de sustituir todo el recurso.
• DELETE: elimina un recurso del servidor. Habitual en las API que gestionan cuentas, publicaciones o archivos almacenados.
• HEAD: idéntico a GET, pero devuelve solo las cabeceras, no el cuerpo. Práctico para comprobar si un recurso existe o ha cambiado.
• OPTIONS: pregunta al servidor qué métodos y cabeceras acepta para un recurso determinado. Los navegadores lo utilizan en las comprobaciones previas de CORS.

Elegir el método adecuado importa no solo por corrección, sino también por el almacenamiento en caché, la seguridad y la forma en que los proxies y las CDN gestionan el tráfico.

Peticiones HTTP síncronas frente a asíncronas: diferencia entre ellas

Cuando se gestiona de forma síncrona, una petición deja todo lo demás en pausa hasta que llega una respuesta. Si se procesa de forma asíncrona, otras tareas pueden continuar mientras tanto, lo que hace que la experiencia resulte más rápida y fluida.

Los sitios web actuales suelen preferir la lógica no bloqueante para ofrecer interacciones de usuario más rápidas y fluidas.

Ventajas y desventajas

Ventajas:

• Puede utilizar varios métodos, incluidos GET, POST o el método PUT
  
• Compatible con todos los navegadores modernos
  
• Permite que distintos sistemas intercambien mensajes de forma clara y predecible
  

Limitaciones:

• El comportamiento bloqueante en modo síncrono puede ralentizar las cosas
  
• El tratamiento de los datos debe hacerse con cautela para evitar exponer información
  
• Algunos formatos de cuerpo de mensaje son difíciles de depurar o interpretar
  
• El significado de muchos códigos de estado no siempre resulta evidente a primera vista
  

Ejemplos

• Una llamada GET que recupera datos de usuario de un perfil
  
• El cuerpo de una petición POST contiene datos de formulario enviados por el usuario, como comentarios, datos de inicio de sesión o información de pago.
  
• Los desarrolladores suelen utilizar peticiones PUT al actualizar un recurso especificado existente
  
• Los métodos DELETE son ideales para eliminar registros almacenados, como cuentas de usuario o archivos subidos. (por ejemplo, eliminar un archivo a través de un endpoint HTTP)
  
• Las publicaciones de los usuarios en los foros suelen crearse mediante POST o modificarse con PUT

Peticiones HTTP frente a HTTPS

Una petición HTTPS es estructuralmente igual que una petición HTTP: los mismos métodos, las mismas cabeceras, el mismo cuerpo. La diferencia está en lo que ocurre a su alrededor.

HTTPS envuelve toda la petición y la respuesta en cifrado mediante TLS. Antes de que se mueva ningún dato, el cliente y el servidor realizan un breve handshake TLS para acordar las claves. A partir de ahí, todo lo que se envía (datos de inicio de sesión, datos de pago, cookies) resulta ilegible para cualquiera que intercepte el tráfico.

El HTTP simple envía todo en texto claro. Eso está bien para contenido estático como un artículo público, pero es un problema para cualquier cosa sensible. Los navegadores modernos marcan los sitios que solo usan HTTP como «No es seguro» y la mayoría de los buscadores esperan ya HTTPS de forma predeterminada.

En la práctica: si una petición transporta credenciales, datos personales o cualquier cosa que no pegaría en público, debería viajar por HTTPS.

Peticiones HTTP y proxies

Un proxy se sitúa entre el cliente y el servidor y reenvía las peticiones HTTP en nombre del cliente. Desde el punto de vista del servidor, la petición procede de la dirección IP del proxy, no del dispositivo original.

Esta configuración resulta útil en varios escenarios. Las herramientas de web scraping rotan entre proxies residenciales o de centro de datos para evitar el rate limiting y los bloqueos. Los profesionales del marketing verifican anuncios desde distintos países enviando peticiones HTTP a través de proxies de esas regiones. Los desarrolladores enrutan el tráfico de pruebas automatizadas a través de proxies para depurar cómo se comporta un servicio en distintas condiciones de red.

Los distintos tipos de proxy gestionan el tráfico HTTP de forma diferente. Los proxies HTTP operan en la capa de aplicación y pueden inspeccionar o modificar las cabeceras. El tráfico HTTPS, al estar cifrado, suele tunelizarse a través de los proxies mediante el método CONNECT sin descifrarlo.

Proxywing ofrece proxies residenciales, proxies de centro de datos, proxies ISP y proxies móviles diseñados específicamente para enrutar peticiones HTTP y HTTPS de forma fiable a gran escala.

Preguntas frecuentes

¿Qué es una petición HTTP en términos sencillos?

Es un mensaje que un navegador o una aplicación envía a un servidor para pedirle que haga algo, normalmente devolver una página web, una imagen o un dato.

¿Cuáles son las partes principales de una petición HTTP?

Una línea de petición (método, ruta, versión del protocolo), las cabeceras (metadatos sobre la petición) y un cuerpo opcional que transporta datos.

¿Cuáles son los métodos HTTP más habituales?

GET (leer), POST (crear), PUT (sustituir), PATCH (actualización parcial), DELETE (eliminar), HEAD (solo cabeceras) y OPTIONS (comprobación de capacidades)

¿Cuál es la diferencia entre una petición HTTP y una petición HTTPS?

La estructura es idéntica. HTTPS añade cifrado TLS alrededor de todo el intercambio para que los datos no puedan leerse ni modificarse en tránsito.

¿Puede fallar una petición HTTP?

Sí. El servidor devuelve un código de estado con cada respuesta: 200 significa éxito, 4xx apunta a un problema del lado del cliente, como una URL incorrecta, y 5xx significa que el propio servidor ha tenido un problema.

¿Cómo gestionan los proxies las peticiones HTTP?

Un proxy recibe la petición del cliente, la reenvía al servidor de destino con su propia IP y devuelve la respuesta. En el caso de HTTPS, el proxy suele tunelizar el tráfico cifrado sin inspeccionar su contenido