HTTP desde un dispositivo

01 · Punto de partida

El idioma de la web

Con el bloque de redes cerrado, el dato ya puede salir del dispositivo y llegar a un servidor por TCP/IP. Ahora hace falta que ambos se entiendan: que el servidor sepa qué es lo que llegó y qué se espera de él. Ése es el trabajo de los protocolos de aplicación, y el primero que vemos es HTTP (HyperText Transfer Protocol), el que usa la web.

HTTP tiene una virtud decisiva para IoT: es el lenguaje que hablan casi todos los servicios. Si querés guardar un dato en una base de datos en la nube, publicar una lectura en una plataforma, consultar la hora o descargar una configuración, lo más probable es que haya una interfaz HTTP. Atraviesa cualquier firewall (el puerto 443 casi siempre está abierto), se puede probar con un navegador o curl, y hay bibliotecas en cualquier plataforma. Tiene también sus costos: es un protocolo de texto con cabeceras pesadas, pensado para páginas web, no para sensores con batería. Este tema enseña a usarlo con los ojos abiertos.

Los fragmentos de C++ siguen el estilo Arduino para ESP32; los nombres de las clases pueden variar entre versiones de la biblioteca.

02 · Estructura

Anatomía de una conversación HTTP

HTTP es un protocolo de pedido y respuesta. El cliente (el dispositivo) envía una petición; el servidor devuelve una respuesta. Ambas tienen la misma forma, en texto plano:

1. Una línea inicial. En la petición: el método, la ruta y la versión. En la respuesta: la versión, el código de estado y su texto.
2. Las cabeceras: pares Nombre: valor, una por línea, con metadatos del mensaje.
3. Una línea en blanco que marca el fin de las cabeceras.
4. El cuerpo (opcional): los datos en sí.

Observá lo que el diagrama muestra: los datos de la lectura ([41]) ocupan unos pocos bytes dentro de un mensaje de más de doscientos. Todo lo demás es el «sobre» necesario para que el servidor sepa a dónde va, qué formato tiene y quién lo envía.

Una aclaración de versiones. Lo que ves es HTTP/1.1, un protocolo de texto que es el más sencillo de implementar en un microcontrolador y el que soporta casi todo. Las versiones más nuevas (HTTP/2 y HTTP/3) son binarias, más eficientes y multiplexan varias conversaciones, pero exigen más memoria y bibliotecas más complejas; en dispositivos pequeños, HTTP/1.1 sigue siendo lo habitual.

03 · Qué pedir y dónde

Métodos y direcciones

El método dice qué se quiere hacer con el recurso. Los cinco más usados:

La idempotencia (el mismo pedido repetido deja el mismo resultado) es la clave para decidir si un método se puede reintentar sin riesgo. Un GET o un PUT repetidos son inocuos. Un POST repetido puede crear dos lecturas iguales: por eso conviene que el cuerpo lleve un identificador único para que el servidor descarte duplicados (tema 18). El tema 20 profundiza en GET y POST.

La URL dice dónde está el recurso. Se compone de partes que ya conocés del tema 17:

• https es el esquema: HTTP sobre TLS (puerto 443 por defecto); http es sin cifrar (puerto 80).
• datos.ejemplo.com es el servidor, que se resuelve por DNS; opcionalmente va un puerto.
• /api/v1/lecturas es la ruta del recurso. Incluir la versión (v1) permite cambiar la interfaz sin romper a los equipos instalados.
• ?dispositivo=c07 es la consulta: parámetros en pares nombre=valor.

04 · Metadatos

Las cabeceras que importan

Las cabeceras son información sobre el mensaje. Hay decenas definidas; para un dispositivo IoT alcanzan unas pocas, y conviene enviar solo las necesarias, porque cada una cuesta bytes en cada petición.

La Authorization merece atención especial. Es la forma habitual de identificar al dispositivo (un token por equipo, nunca uno compartido por toda la flota), y solo es seguro sobre HTTPS: sobre HTTP, el token viaja a la vista de cualquiera. Y la cabecera Date es un regalo: cada respuesta trae la hora del servidor, una forma gratuita de poner en hora el reloj del dispositivo, algo necesario para validar certificados.

05 · Interpretar la respuesta

Códigos de estado: qué hacer con cada uno

La primera cosa que mira un cliente al recibir la respuesta es el código de estado: un número de tres cifras cuya primera cifra indica la familia. Un cliente de dispositivo no se limita a «anduvo o no anduvo»: decide qué hacer según el código.

La regla de fondo, que enlaza con el tema 18: los códigos 4xx son errores del cliente (el dispositivo hizo algo mal) y reintentar el mismo pedido dará el mismo resultado, con el costo de energía y de tráfico; los 5xx son errores del servidor y suelen ser transitorios. La excepción son 408 y 429, que son 4xx pero se recuperan con tiempo. Y el 429 trae una instrucción explícita: obedecé el Retry-After. Ignorarla es la mejor forma de que el servidor bloquee al dispositivo.

06 · Programar el cliente

Un cliente HTTP en el microcontrolador

Las plataformas con Wi-Fi traen una biblioteca de cliente HTTP que se ocupa de abrir la conexión, armar las cabeceras y leer la respuesta. El siguiente fragmento envía una lectura por POST sobre HTTPS, con tiempo máximo y manejo de los resultados:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <HTTPClient.h>
#include "secretos.h"                          // define TOKEN_DISPOSITIVO y el certificado raíz CERT_RAIZ

// Devuelve: 0 = enviado, 1 = reintentar más tarde, 2 = error permanente
int enviarLectura(const String &json) {
  WiFiClientSecure cliente;
  cliente.setCACert(CERT_RAIZ);                // verificar el certificado del servidor (tema 41)
  HTTPClient http;
  http.setTimeout(5000);                       // 5 s como máximo en cada espera
  if (!http.begin(cliente, "https://datos.ejemplo.com/api/v1/lecturas")) return 1;
  http.addHeader("Content-Type", "application/json");
  http.addHeader("Authorization", String("Bearer ") + TOKEN_DISPOSITIVO);

  int codigo = http.POST(json);
  int resultado;
  if (codigo < 0) {                            // la biblioteca no pudo completar la petición
    Serial.print("Error de red: ");
    Serial.println(HTTPClient::errorToString(codigo));
    resultado = 1;                             // sin red, sin DNS, sin conexión o sin respuesta: reintentar
  } else if (codigo >= 200 && codigo < 300) {
    resultado = 0;                             // éxito
  } else if (codigo == 408 || codigo == 429 || codigo >= 500) {
    resultado = 1;                             // falla transitoria
  } else {
    Serial.printf("Rechazado con código %d\n", codigo);
    resultado = 2;                             // 400, 401, 403, 404...: no reintentar igual
  }
  http.end();                                  // liberar la conexión y la memoria
  return resultado;
}

Tres decisiones de este fragmento reflejan lo aprendido. Una: los códigos negativos son errores de la biblioteca, no del servidor (conexión rechazada, tiempo agotado, sin respuesta) y se tratan como fallas de red: el dato queda en el buffer y se reintenta. Otra: cada código se traduce en una de tres acciones: listo, reintentar o descartar el reintento. Y otra más: se llama a http.end() siempre, porque la memoria de un microcontrolador es escasa y una conexión abierta olvidada la agota.

Dos cuidados de memoria y de seguridad. Primero, no cargar respuestas grandes completas en RAM: una respuesta de 100 KB no entra en un microcontrolador chico. Se lee por trozos y se procesa a medida que llega (o se limita el tamaño máximo aceptado). Segundo, las respuestas pueden venir en transferencia fragmentada (Transfer-Encoding: chunked) cuando el servidor no conoce de antemano el largo; las bibliotecas lo manejan, pero hay que contar con que no hay Content-Length. Y si se usa HTTPS, se verifica el certificado del servidor: desactivar la verificación «para que ande» deja la puerta abierta a quien se interponga (bloque de seguridad).

07 · Elegir con criterio

Cuándo conviene HTTP y cuánto cuesta

HTTP es el punto de partida más simple para llevar datos a un servidor, pero no siempre el más eficiente. Pesan tres costos que ya conocés de temas anteriores:

• Bytes. Las cabeceras de una petición suelen ser mucho más grandes que unos pocos bytes de datos. Una lectura de 53 bytes útiles puede viajar en unos 270 a 880 bytes.
• Viajes. Cada petición sobre una conexión nueva paga DNS, TCP y TLS (tema 17): hasta cinco viajes de ida y vuelta para un dato.
• Energía. Todo lo anterior es tiempo de radio encendida (tema 14).

El truco que hace razonable a HTTP en muchos casos es el que ya vimos: pocos envíos, con lotes de lecturas, cabeceras mínimas y conexión cifrada reutilizada. Un POST por hora con sesenta lecturas pesa casi lo mismo en cabeceras que un POST con una sola, y reparte esos bytes entre sesenta medidas.

08 · Analogía con programación

Medir una petición en Python

El programa construye peticiones y respuestas HTTP reales, línea por línea, y cuenta sus bytes. Prueba tres juegos de cabeceras: mínimas (solo las imprescindibles), habituales (agregan el agente de usuario, el formato aceptado y la credencial) y pesadas (suman idioma, cookie, control de caché e identificador de petición, como una aplicación web típica). El cuerpo es el mensaje compacto del tema 12 con 1, 10 o 60 lecturas. Al final imprime una petición completa y una función accion que traduce cada código de estado a una decisión.

import json

HOST = "datos.ejemplo.com"
RUTA = "/api/v1/lecturas"
TOKEN = "k7Qz3Wm9Xr2Lp5Ty8Vb1Nc4Jd6Hf0Gs3Aa5Ze7Uo9Ii2Eu4Ow"[:43]
COOKIE = "a1b2c3d4" * 8
UUID = "123e4567-e89b-12d3-a456-426614174000"


def cuerpo(n):
    """Mensaje compacto con n lecturas de temperatura (décimas de grado)."""
    valores = [41 + (i * 3) % 8 for i in range(n)]
    return json.dumps({"d": "c07", "t": 1794061920, "i": 60, "v": valores}, separators=(",", ":"))


def peticion(n, juego):
    cuerpo_json = cuerpo(n)
    lineas = [f"POST {RUTA} HTTP/1.1",
              f"Host: {HOST}",
              "Content-Type: application/json",
              f"Content-Length: {len(cuerpo_json)}",
              "Connection: close"]
    if juego in ("habituales", "pesadas"):
        lineas += ["User-Agent: sensor-esp32/1.2.0", "Accept: application/json", f"Authorization: Bearer {TOKEN}"]
    if juego == "pesadas":
        lineas += ["Accept-Language: es-AR,es;q=0.9", f"Cookie: sesion={COOKIE}", "Cache-Control: no-cache", f"X-Request-Id: {UUID}"]
    return "\r\n".join(lineas) + "\r\n\r\n" + cuerpo_json


def respuesta(juego):
    cuerpo_json = '{"ok":true}'
    lineas = ["HTTP/1.1 200 OK",
              "Content-Type: application/json",
              f"Content-Length: {len(cuerpo_json)}",
              "Connection: close"]
    if juego in ("habituales", "pesadas"):
        lineas += ["Date: Sat, 07 Nov 2026 14:32:01 GMT", "Server: nginx/1.25.3"]
    if juego == "pesadas":
        lineas += [f"Set-Cookie: sesion={COOKIE}; Path=/; HttpOnly; Secure", "Cache-Control: no-store",
                   f"X-Request-Id: {UUID}", "Strict-Transport-Security: max-age=31536000"]
    return "\r\n".join(lineas) + "\r\n\r\n" + cuerpo_json


print("cabeceras    lecturas  útil   petición  respuesta  total   % útil")
for juego in ("mínimas", "habituales", "pesadas"):
    clave = "minimas" if juego == "mínimas" else juego
    for n in (1, 10, 60):
        util = len(cuerpo(n)) + len('{"ok":true}')
        pet = len(peticion(n, clave))
        res = len(respuesta(clave))
        total = pet + res
        print(f"{juego:<12} {n:>7} {util:>6} {pet:>9} {res:>10} {total:>7} {100 * util / total:>7.1f} %")

print()
print(peticion(1, "habituales"))


def accion(codigo):
    if 200 <= codigo < 300:
        return "éxito: seguir"
    if codigo in (301, 302, 307, 308):
        return "redirección: seguir la nueva dirección, con límite de saltos"
    if codigo in (408, 429, 500, 502, 503, 504):
        return "falla transitoria: reintentar con espera creciente"
    if 400 <= codigo < 500:
        return "error del cliente: no reintentar, corregir y reportar"
    return "otro: registrar y reportar"


print()
for codigo in (200, 201, 204, 302, 400, 401, 404, 408, 429, 500, 503):
    print(codigo, "->", accion(codigo))

Resultado con los valores iniciales. Con cabeceras mínimas, una lectura por petición necesita 172 bytes de petición y 101 de respuesta (273 en total, de los cuales 53 son datos: 19,4 %); con 10 lecturas, 300 bytes (26,7 % útil); con 60, 451 bytes (51,0 %). Con cabeceras habituales: 457, 484 y 635 bytes (11,6 %, 16,5 % y 36,2 % útil). Con cabeceras pesadas: 881, 908 y 1059 bytes (6,0 %, 8,8 % y 21,7 %). En cuanto a los códigos, 200, 201 y 204 se consideran éxito; el 302 es una redirección; 408, 429, 500 y 503 son transitorios y se reintentan con espera creciente; y 400, 401 y 404 son errores del cliente que no se reintentan.

Las cifras dicen tres cosas. Una: con una lectura por petición, la mayor parte del tráfico son cabeceras, incluso con las mínimas. Otra: las cabeceras de más se pagan en cada envío: las «pesadas» triplican el tamaño de la conversación sin aportar nada que el dispositivo use. Y la tercera: agrupar sesenta lecturas baja el costo por lectura de 273 a 7,5 bytes, 36 veces menos, con las mismas cabeceras mínimas.

09 · Exploración interactiva

¿Cuánto pesa una petición?, de extremo a extremo

Este laboratorio construye las mismas peticiones y respuestas que el código anterior y cuenta sus bytes. Elegí cuántas lecturas lleva el cuerpo y qué conjunto de cabeceras usa el cliente. Cada barra muestra el tráfico total de una conversación completa (petición y respuesta) dividido en: la línea inicial con las cabeceras mínimas, las cabeceras adicionales de la petición, las cabeceras de la respuesta y los datos útiles.

Recorrido guiado

1. Con los valores iniciales (10 lecturas, cabeceras habituales), armá la petición. 324 bytes de petición y 160 de respuesta: 484 en total, 16,5 % de datos y 48,4 bytes por lectura: «Aceptable».
2. Cambiá a 1 lectura: 457 bytes en total y apenas 11,6 % de datos. «Casi todo es sobre»: 457 bytes de tráfico por una sola medida.
3. Pasá a cabeceras mínimas con 1 lectura: 273 bytes y 19,4 %. Quitar cabeceras que el servidor no necesita ahorró 184 bytes por envío.
4. Elegí Con cookies y rastreo y 1 lectura: 881 bytes y 6,0 % de datos. Las cabeceras de una aplicación web pesan más del triple que las mínimas.
5. Con cabeceras mínimas, subí a 60 lecturas: 451 bytes en total, 51,0 % de datos y 7,5 bytes por lectura: «Eficiente». El mismo cliente, 36 veces menos tráfico por lectura.
6. Con 60 lecturas y cabeceras pesadas: 1059 bytes y 21,7 %. Aun así 17,7 bytes por lectura, menos que una lectura suelta con cabeceras mínimas. Agrupar es más rentable que podar cabeceras, y lo mejor es hacer ambas cosas.

10 · Método de trabajo

Lista de verificación de un cliente HTTP

1. HTTPS siempre para credenciales y datos, con verificación del certificado.
2. Cabeceras mínimas: Host, Content-Type, Content-Length, Authorization y poco más.
3. Un token por dispositivo, revocable, guardado en memoria no volátil.
4. Tiempos máximos en la conexión y en la lectura de la respuesta.
5. Decisión por código: éxito, reintento con espera creciente o descarte del reintento, según la tabla de estados; respetar Retry-After.
6. Lotes: varias lecturas por petición, con identificador para descartar duplicados.
7. Memoria: limitar el tamaño de las respuestas aceptadas y liberar siempre la conexión.
8. Redirecciones con límite de saltos y sin bajar de HTTPS a HTTP.
9. Hora: aprovechar la cabecera Date de las respuestas para mantener el reloj.
10. Pruebas: contra un servidor que responda cada código (200, 401, 404, 429, 500, 503), que tarde de más y que corte a mitad de la respuesta.

Una herramienta valiosa en el escritorio: probá primero la misma petición con curl -v y comprobá que el servidor responde lo esperado. Si anda en curl y no en el dispositivo, el problema está en el firmware o en la red del dispositivo, no en la interfaz.

11 · Comprensión

Confusiones frecuentes

12 · Práctica guiada

Predecí antes de comprobar

1. Armar una cabecera

El cuerpo de una petición es {"t":22.3}. ¿Qué valor lleva la cabecera Content-Length? ¿Y qué cabecera indica que es JSON?

2. Qué hacer con cada código

Indicá si reintentarías y cómo: (a) 503; (b) 401; (c) 429 con Retry-After: 120; (d) 404; (e) 500 por tercera vez seguida.

3. Idempotencia

Un POST de una lectura llega al servidor pero la respuesta se pierde, y el dispositivo lo reenvía. ¿Qué ocurre y cómo se evita el daño?

4. Costo de las cabeceras

Una lectura suelta con cabeceras mínimas pesa 273 bytes en total (53 de datos). Sesenta lecturas en un lote con las mismas cabeceras pesan 451. ¿Cuántos bytes por lectura en cada caso y cuántas veces menos?

5. Redirección

Una petición a http://datos.ejemplo.com/api recibe un 301 con Location: https://datos.ejemplo.com/api. ¿Qué debe hacer el dispositivo? ¿Y si el Location apuntara a un servidor http:// distinto?

6. Errores de la biblioteca

Una llamada a http.POST devuelve −1. ¿Qué significa en general y qué hace el firmware con la lectura?

13 · Síntesis

Ideas para recordar

¿Listo para el tema 20?

Antes de avanzar, probá con curl -v una petición POST a un servicio de prueba y mirá cada línea de la conversación. Contá los bytes de petición y respuesta, marcá cuáles cabeceras el servicio realmente necesita y calculá cuánto ahorrarías en una flota de mil equipos si las demás se quitaran.

En el próximo tema trabajamos con las peticiones GET y POST: cómo el dispositivo lee su configuración del servidor, cómo envía lecturas y qué diferencias hay en el diseño de uno y otro.