HTTP es el protocolo de comunicación que usan las APIs REST para enviar y recibir información entre aplicaciones a través de internet.
El momento en que todo cambió para Rodrigo
Rodrigo trabaja como desarrollador junior en una empresa de logística en Monterrey. Un martes a las 11:47 de la mañana, su aplicación dejó de mostrar los precios de envío. No había error de código. No había falla de servidor. El problema era más sutil: su aplicación estaba "hablando" con la API de su proveedor, pero nadie estaba escuchando. O más exacto: estaba hablando en el idioma equivocado.
Lo que Rodrigo no sabía en ese momento es que HTTP no es solo un canal por donde viaja la información. HTTP es un lenguaje completo, con verbos, reglas y respuestas específicas. Y cuando no usas ese lenguaje correctamente, las APIs simplemente no responden.
El idioma secreto que conecta al mundo digital
HTTP significa "HyperText Transfer Protocol". Es el mismo protocolo que tu navegador usa cuando abres cualquier página web. Pero en el contexto de las APIs REST, HTTP cumple un rol mucho más preciso: define exactamente qué quieres hacer y con qué recurso.
Piénsalo así. Cuando entras a Mercado Libre y buscas un teléfono, tu navegador le envía una solicitud HTTP al servidor de Mercado Libre. El servidor recibe esa solicitud, la procesa y te responde con los resultados. Ese intercambio ocurre en menos de 500 milisegundos, millones de veces al día, en todo México y América Latina. HTTP es la infraestructura invisible que lo hace posible.
Lo que hace a HTTP tan poderoso para las APIs REST es su estructura. Cada mensaje HTTP tiene dos partes fundamentales: la solicitud (request) y la respuesta (response).
La anatomía de una solicitud HTTP
Cuando tu aplicación le pide algo a una API, envía una solicitud HTTP. Esa solicitud contiene tres elementos clave.
Primero está el método (o verbo HTTP). Es la acción que quieres realizar. Segundo está la URL del recurso, que indica dónde vive la información que buscas. Tercero está el cuerpo del mensaje (body), que contiene los datos adicionales cuando los necesitas, como cuando quieres crear o actualizar algo.
Los métodos HTTP son el corazón de todo esto. En las APIs REST, cuatro métodos concentran el 95% de todo el trabajo:
GET — Solicita información. No modifica nada. Solo lee.
POST — Envía datos para crear algo nuevo.
PUT — Reemplaza o actualiza un recurso existente.
DELETE — Elimina un recurso.
Esta combinación de cuatro métodos tiene un nombre técnico: CRUD (Create, Read, Update, Delete). Y aunque suena a jerga, en la práctica describe casi todo lo que una aplicación necesita hacer con datos.
GET y POST en acción: el ejemplo de Liverpool
Imagina que trabajas en el equipo de tecnología de Liverpool. Tienes una API que gestiona el inventario de productos. Veamos cómo funciona cada método en la vida real.
Cuando un cliente entra a la página de Liverpool y busca una televisión, tu aplicación hace esto:
GET /api/productos?categoria=televisiones
El servidor recibe esa solicitud y responde con una lista de televisiones disponibles. No cambia nada en la base de datos. Solo lee y devuelve. Esa es la filosofía de GET: observar sin tocar.
Ahora imagina que Liverpool lanza un producto nuevo: una televisión OLED de 65 pulgadas. El equipo de inventario necesita agregarla al catálogo. Para eso se usa POST:
POST /api/productos
Content-Type: application/json
{
"nombre": "Televisión OLED 65 pulgadas",
"precio": 28500,
"stock": 150
}
El servidor recibe esos datos, crea el nuevo producto y responde confirmando que todo salió bien. El producto ahora existe en el sistema. POST crea, GET lee. Dos verbos, dos responsabilidades completamente distintas.
PUT y DELETE: actualizar y eliminar con precisión
Unos días después, Liverpool decide ajustar el precio de esa televisión. El precio baja a $25,900. Para actualizar ese producto específico, se usa PUT:
PUT /api/productos/4821
Content-Type: application/json
{
"nombre": "Televisión OLED 65 pulgadas",
"precio": 25900,
"stock": 143
}
Observa el número 4821 en la URL. Ese es el identificador único del producto. PUT necesita saber exactamente qué recurso va a reemplazar. No puedes usar PUT sin apuntar a un recurso específico.
Finalmente, si Liverpool descontinúa ese modelo y necesita eliminarlo del catálogo:
DELETE /api/productos/4821
Una sola línea. Sin cuerpo adicional. El servidor recibe la instrucción, elimina el recurso y confirma la acción. DELETE es el método más directo de todos.
La respuesta del servidor: códigos de estado HTTP
Cada vez que tu aplicación envía una solicitud, el servidor responde con dos cosas: los datos solicitados (si los hay) y un código de estado HTTP. Ese código es la forma en que el servidor te dice qué pasó.
Los códigos se agrupan en familias según su primer dígito. Los más importantes en el trabajo diario con APIs son:
200 OK — Todo salió perfecto. La solicitud fue procesada correctamente.
201 Created — El recurso fue creado exitosamente. Normalmente responde a un POST.
400 Bad Request — Tu solicitud tiene algún error. Quizá te faltó un campo obligatorio.
401 Unauthorized — No enviaste credenciales o son incorrectas.
404 Not Found — El recurso que buscas no existe. Como buscar el producto 9999 cuando no hay ninguno con ese ID.
500 Internal Server Error — El servidor tuvo un problema interno. El error no es tuyo.
En México, cuando consumes la API del SAT o del IMSS, estos códigos son tu primera pista para diagnosticar qué salió mal. Un desarrollador que sabe leer códigos de estado resuelve problemas en minutos, no en horas.
Errores comunes al trabajar con métodos HTTP
Aquí es donde muchos desarrolladores tropiezan al inicio. El error más frecuente es usar GET cuando deberías usar POST. Algunos programadores novatos intentan enviar datos sensibles en la URL, como contraseñas o números de tarjeta, usando GET. Eso es un error grave: los parámetros de GET quedan expuestos en los registros del servidor y en el historial del navegador.
Otro error clásico es confundir PUT con POST. Si usas POST para actualizar un recurso existente, algunos servidores crearán un duplicado en lugar de actualizarlo. La consecuencia en un sistema de inventario como el de FEMSA podría ser tener el mismo producto registrado dos veces, con stock duplicado y precios distintos.
Finalmente, muchos desarrolladores ignoran los códigos de estado en sus aplicaciones. En lugar de leer el código 404 y mostrar un mensaje útil al usuario, simplemente muestran una pantalla en blanco. Leer y manejar correctamente los códigos de estado es lo que separa a una aplicación robusta de una que falla en silencio.
El cierre del problema de Rodrigo
Volvamos a Rodrigo en Monterrey. Cuando revisó con más calma su código, encontró el problema: estaba usando GET para enviar los parámetros de su solicitud de precios, pero la API del proveedor esperaba un POST con esos datos en el cuerpo del mensaje. Eran dos métodos distintos, con comportamientos distintos.
Cambió el método, volvió a probar y en segundos los precios de envío aparecieron correctamente en su aplicación. Un solo cambio de verbo. Eso es todo lo que hacía falta.
HTTP no es solo una tubería por donde fluyen datos. Es un contrato preciso entre tu aplicación y el servidor. Cuando entiendes sus reglas, tienes el control. Cuando las ignoras, estás adivinando. Y en el desarrollo de software profesional, adivinar sale muy caro.
Lo que cambia cuando dominas HTTP
En México, las empresas que construyen sobre APIs REST, desde startups hasta corporativos como Bimbo o FEMSA, buscan desarrolladores que entiendan HTTP a fondo. No solo que sepan "qué hace GET", sino que entiendan por qué cada método existe y cuándo usarlo con precisión.
Dominar HTTP es el primer paso real para trabajar con APIs de forma profesional. Todo lo demás, autenticación, manejo de errores, optimización, se construye sobre esta base.