La web sin páginas — APIs REST y datos en JSON

Hasta ahora has visto la web clásica: escribes una dirección, el servidor te devuelve un documento HTML con textos, enlaces y botones, y tu navegador lo dibuja en pantalla. Pero cuando usas la app del banco en tu teléfono, o pides un taxi, o miras el tiempo, no estás descargando páginas web: la app habla con el servidor mediante una API (interfaz de programación de aplicaciones).

En una API web (habitualmente de estilo REST), el cliente no pide un diseño visual: pide datos en bruto. Pide GET /api/v1/citas y el servidor le devuelve la lista de citas sin estilos ni colores. La app en tu móvil se encarga de pintarlo bonito.

Lo que no cambia es el transporte: sigue siendo el mismo protocolo HTTP que aprendiste en la primera sala, con sus verbos (GET, POST), sus códigos de estado y sus cabeceras.

Cuando un servidor de API responde o recibe datos, necesita un formato que cualquier lenguaje de programación pueda entender: Python, Java, JavaScript o Swift. Ese formato universal se llama JSON (JavaScript Object Notation).

Un mensaje en JSON es texto plano organizado en parejas de nombre: valor, encerradas entre llaves:

{
  "paciente": "Elena Ramos",
  "habitacion": 104,
  "activo": true
}

Es fácil de leer para un humano y trivial de procesar para un computador. La lección de seguridad: un JSON es texto que viaja por la red, y todo lo que aprendiste sobre desconfiar de lo que manda el usuario aplica exactamente igual a cada campo dentro de un JSON.

Aquí está la razón por la que quien se dedica a seguridad no se queda mirando la pantalla del navegador: la interfaz visual es solo una sugerencia.

Imagina un formulario web de la clínica donde el botón de «Borrar historial» está en gris, bloqueado porque tu usuario no tiene permiso. Si te quedas en el navegador, parece que no puedes borrarlo. Pero quien entiende cómo funciona la web mira qué petición envía ese botón: un DELETE /api/historial/104.

Si envías esa petición HTTP directamente al servidor usando una herramienta de terminal o un script, te has saltado por completo el botón gris. Si el servidor no comprueba tus permisos por dentro y solo confiaba en que el botón estuviera bloqueado en el navegador, el historial se borra.

Regla de oro: Las restricciones que solo existen en la pantalla del usuario no protegen nada. La seguridad se comprueba siempre en el servidor.

En la web tradicional, tu navegador guardaba una cookie de sesión tras iniciar sesión. En las APIs modernas —especialmente las que atienden a aplicaciones móviles o arquitecturas en la nube—, el servidor suele entregar un token (una cadena larga de caracteres que funciona como un pase de entrada digital).

Con cada petición que la aplicación envía a la API, adjunta ese token en una cabecera HTTP:

Authorization: Bearer eyJhbGciOiJIUzI1Ni...

La palabra Bearer significa «el portador»: quien lleve ese pase en la mano tiene el acceso que el token autoriza. Por eso robar un token de API en un teléfono o interceptarlo en una red sin cifrar equivale a robar la llave completa de la sesión. Cuidar cómo se guardan y cómo viajan esos tokens es la base de la seguridad en aplicaciones móviles y modernas.