apis Mac & Windows

Anatomía de una petición HTTP

datablog apis
Actualizado: 2026-05-23

1. Qué es

Una petición HTTP es la "palmadita" — un mensaje que alguien le manda a una máquina diciéndole "haz algo". Es la forma en que internet se comunica.

Todo lo que pasa en internet es una petición HTTP: cargar una página, enviar un formulario, llamar un URL de Cloud Run, hacer click en un botón.

2. Las partes de una petición

Toda petición HTTP tiene dos partes obligatorias:

  1. A quién le hablas — el URL: https://mi-script.run.app
  2. Qué le pides — el método

Y dos partes opcionales:

  1. Headers — metadatos de la petición (quién eres, qué formato envías, etc.)
  2. Body — datos adicionales que envías (solo en POST, PUT)

Técnicamente, la URL y el método viajan juntos en la misma línea — la línea de inicio (GET /posts/1 HTTP/1.1). Los separamos aquí para entenderlos mejor.

3. Los métodos — tipos de palmadita

Método Qué significa Cuándo usarlo
GET "dame información" buscar, consultar, cargar una página
POST "toma esto y procésalo" enviar datos, crear algo nuevo
PUT "reemplaza esto" actualizar algo existente
DELETE "borra esto" eliminar algo

El más común al principio es GET. Cuando escribes un URL en el navegador estás haciendo un GET.

4. Desde dónde se pueden hacer palmaditas

  • Navegador — escribes el URL y das enter (siempre es GET)
  • Terminal — con curl "http://localhost:8000/?texto=hola"
  • Código Python — con la librería requests
  • Postman — herramienta visual para probar APIs, útil para POST

En este post solo cubrimos el navegador y curl. Python con requests y Postman los vemos en temas propios.

5. Tu primera palmadita GET consciente

Ya sabes que el navegador y curl hacen lo mismo — un GET. La diferencia es lo que te muestran.

Empieza por el navegador. Abre esta URL:

https://jsonplaceholder.typicode.com/posts/1

Verás el body directamente — el navegador esconde todo lo demás. 

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

Ahora haz lo mismo desde la terminal:

curl "https://jsonplaceholder.typicode.com/posts/1"

Mismo resultado: solo el body. Curl y el navegador hicieron exactamente el mismo GET — la petición fue idéntica.

Ahora agrega -i:

curl -i "https://jsonplaceholder.typicode.com/posts/1"

Y verás algo que el navegador nunca te muestra — los headers antes del body:

HTTP/2 200
content-type: application/json; charset=utf-8
x-ratelimit-limit: 1000
x-ratelimit-remaining: 999
...

{ "userId": 1, "id": 1, "title": "sunt aut facere..." }

Para verlos en el navegador: DevTools (Cmd + Option + I) → pestaña Red → click en cualquier petición → pestaña Headers.

La diferencia: sin -i curl se comporta igual que el navegador — te da solo el contenido. Con -i le dices "muéstrame también los metadatos del viaje". Ambas partes viajaron siempre — -i solo las hace visibles.

Eso que acabas de ver es exactamente lo que exploramos en la siguiente sección.

6. Headers

6.1 Headers de petición — lo que el cliente envía

Cuando abres una URL en el navegador o ejecutas un curl, no solo estás enviando el método y la URL — también estás enviando headers de forma automática, sin escribirlos tú. El navegador y curl los añaden solos. Una petición típica lleva entre 8 y 15:

Header Qué dice
user-agent Quién hace la petición — Chrome en Mac, curl, un script de Python
accept Qué formatos acepta el cliente (application/json, text/html)
accept-language Idioma preferido del cliente
if-none-match El etag guardado — pregunta al servidor "¿cambió desde la última vez?"
cache-control: max-age=0 "No uses caché, dame la versión fresca"

6.2 Headers de respuesta — los más importantes

El servidor responde con sus propios headers. No hay límite universal — cada servidor fija el suyo. Una respuesta típica lleva entre 5 y 10. Hay headers estándar (casi todos los servidores los envían) y personalizados (prefijo x-):

Header Qué dice
content-type Qué formato tiene el body (application/json, text/html)
content-length Cuántos bytes pesa la respuesta
cache-control: max-age=N Cuántos segundos puede el navegador usar la respuesta sin preguntar de nuevo
etag Huella digital del contenido — el navegador la guarda para preguntar si cambió
x-ratelimit-limit Máximo de peticiones permitidas en el período
x-ratelimit-remaining Cuántas quedan antes del bloqueo
server Qué software usa el servidor (cloudflare, nginx, etc.)

7. Las 3 partes de una respuesta

Ya conoces los headers de respuesta — los vimos en la sección 6. Pero una respuesta completa tiene 3 partes, y ya las viste todas en la sección 5 con curl -i:

HTTP/2 200                        ← 1. Línea de estado
content-type: application/json    ← 2. Headers
x-ratelimit-limit: 1000
                                  ← línea en blanco
{ "userId": 1, "id": 1, ... }    ← 3. Body

7.1 Línea de estado

La primera línea de toda respuesta. Contiene la versión del protocolo y el status code — un número que dice cómo fue:

  • 200 — ok
  • 304 — no modificado (el navegador tiene la versión en caché)
  • 400 — petición mal formada
  • 401 — no autenticado (falta credencial)
  • 403 — prohibido (tienes credencial pero no permiso)
  • 404 — no encontrado
  • 422 — datos faltantes u inválidos (FastAPI lo usa cuando falta un parámetro obligatorio)
  • 500 — error interno del servidor

7.2 Body

El body existe en dos direcciones:

Body de respuesta — lo que el servidor te manda de vuelta. No todas las respuestas lo tienen (un 204 no lleva body):

  • JSON: {"userId": 1, "id": 1, ...} — cuando es una API
  • HTML: <html>...</html> — cuando es una página web

Body de petición — lo que tú envías al servidor en un POST o PUT:

  • Solo existe en métodos que mandan datos — GET no tiene body de petición
  • Viaja oculto, no aparece en la URL
  • Generalmente JSON: {"nombre": "Ángel", "email": "..."}

En el GET que hiciste anteriormente no había body de petición — solo línea de inicio y headers. El body de petición aparece cuando un formulario manda tus datos o cuando un script envía información a una API.

8. Qué sigue

Ya entiendes cómo funciona una petición GET — la más simple. Sabes que tiene una línea de inicio, headers y un body de respuesta, y que el navegador y curl hacen lo mismo aunque te muestren cosas distintas.

El siguiente paso es hacer un POST: enviar datos tú mismo y autenticarte en una API real. Ahí aparece el body de petición en la práctica, y entenderás por qué la mayoría de APIs requieren credenciales y cómo se envían.

Referencia oficial