Sector Zero / Desarrollo web
Lo que pasa
detrás del
botón.
APIs, explicadas jugando.
Primero, algo que ya conoces
Tocas un botón. Algo responde.
Elige una acción y sigue su mensaje.
Antes del clic, piensa qué información necesita esa pantalla.
Situaciones para aprender. Las pantallas no se conectan a estos juegos.
Como pedir un helado
Puedes pedirlo sin entrar a la cocina.
El menú dice qué puedes pedir y cómo hacerlo.
Tú
Pides un helado
Menú y pedido
Opciones y reglas
Cocina
Prepara lo pedido
Quieres un helado de chocolate. Todavía no has pedido nada.
En la analogía, el menú y las reglas representan la interfaz. La cocina hace el trabajo.
Ahora sí, el nombre
Una API es una forma acordada de pedirle algo a un programa.
Define lo que puedes pedir, cómo lo pides y qué puedes recibir.
Mi inventario
La información o acción que existe.
Con mi sesión
Los datos y permisos necesarios.
Objetos o un error
El formato de la respuesta.
API significa Application Programming Interface. En español, interfaz de programación de aplicaciones.
Actividad 01 · 6 minutos
Vamos a ser la API.
Tres personas, un menú y pedidos que pueden fallar.
Cliente
Pide un helado y espera la respuesta.
Entrada de la API
Acepta sabor y tamaño del menú. Rechaza pedidos incompletos.
Cocina
Comprueba existencias y entrega el resultado.
Los pedidos
Chocolate, chico. Hay existencias.
Quiero algo rico. Falta información.
Mango, grande. El sabor está agotado.
Una solicitud puede estar bien escrita y aun así no poder completarse. La respuesta también debe seguir reglas.
Fortnite · Abrir el inventario
La pantalla pide. El servicio comprueba.
El juego necesita saber qué objetos pertenecen a tu cuenta.
Tu juego
Abre el inventario
Entrada del servicio
Recibe la solicitud
Lógica del juego
Comprueba tu sesión
Datos de la cuenta
Busca tus objetos
Tocas Inventario. La pantalla necesita la lista de tu cuenta.
Diagrama didáctico inspirado en la acción. No describe endpoints internos de Fortnite. Epic documenta servicios para desarrolladores, como lobbies y sesiones en EOS.
League of Legends · Un caso documentado
Una web puede pedir datos de una partida.
Riot publica APIs para que aplicaciones autorizadas consulten información del juego.
GET /lol/match/v5/matches/{matchId}{
"partida": "DEMO-101",
"campeon": "Ahri",
"resultado": "Victoria",
"kda": "8 / 2 / 11"
}Tu frontend convierte estos datos en una tarjeta.
Ruta de la API oficial. Las partidas y la respuesta mostradas son ficticias y simplificadas. No usamos claves de Riot.
VALORANT · Datos con permiso
Poder pedir un dato no significa poder verlo.
Para estadísticas personales en apps de terceros, Riot exige que el jugador autorice compartir sus datos.
Estadísticas de Luna
Una app de terceros quiere mostrar sus partidas.
Primero, prueba sin permiso.
La existencia de una API no concede acceso a todos los datos.
Simulación del consentimiento. Riot usa RSO y exige acceso de producción para integrarlo. Las políticas tienen excepciones para datos agregados y tablas oficiales.
Marvel Rivals · Un grupo esperando
Tu estado cambia. Tu equipo se entera.
Una acción puede producir un cambio y un aviso para otras pantallas.
Cada pantalla necesita conocer el estado del grupo.
- Esperando una acción del grupo.
Simulación inspirada en un grupo de jugadores. No afirmamos que Marvel Rivals ofrezca una API pública ni que use este protocolo.
Una API puede estar en distintos lugares
A veces hablas con tu dispositivo. A veces con otro servidor.
Dibujar o reproducir audio
Una API del navegador o del motor ofrece funciones en tu dispositivo.
Consultar una cuenta
Una API de red permite hablar con un servicio en otra máquina.
Una API es una interfaz. Una API web es una de sus formas.
Tipos según quién puede usarlos
La puerta también tiene permisos.
Dentro del equipo
Un servicio interno consulta el inventario de una cuenta.
Integraciones acordadas
Un proveedor autorizado conecta su servicio al juego.
Interfaz documentada
Una aplicación registrada consulta una API con sus reglas y límites.
Pública no significa sin autenticación, sin permisos, sin coste ni sin límites.
Hablemos de la web
HTTP organiza solicitudes y respuestas.
Una API de estilo REST suele usar HTTP y rutas para trabajar con recursos.
Cliente
Quiero mis objetos
Recurso
/api/inventario
Servidor
Responde a la petición
El cliente prepara una solicitud HTTP.
Recurso es aquello con lo que trabajas, como un perfil, una partida o un objeto.
Anatomía de una solicitud
Qué quiero, dónde y con qué datos.
Toca cada parte del mensaje.
Método
La acción que pido. Aquí, modificar una parte del perfil.
Query parameters, como ?limite=3, sirven para filtros y opciones. No escribas secretos en una URL.
La respuesta puede ser una ficha de datos
JSON guarda pares de nombre y valor.
La web recibe datos y decide cómo mostrarlos.
{
"apodo": "Luna",
"nivel": 12,
"listo": true,
"objetos": [
"Escudo",
"Poción"
]
}Toca un campo de la ficha.
JSON es un formato de texto. No es una base de datos ni código que debamos ejecutar.
Conecta con CRUD
Cuatro acciones para nuestro inventario.
/api/inventarioLeer los objetosRead/api/inventarioCrear un objeto de prácticaCreate/api/inventario/i1Cambiar parte del objetoUpdate/api/inventario/i1Eliminar el objetoDeletePUT suele reemplazar la representación completa. PATCH modifica parte. El contrato define los detalles y los permisos.
Inventario de práctica. Una API real no permite crear objetos de un juego sólo por enviar POST.
El número cuenta qué pasó
Una respuesta también puede explicar un problema.
Todo bien
Aquí está tu inventario.
Actividad 02 · Decide antes de revelar
¿Qué mensaje mandarías?
Quiero ver el inventario sin cambiarlo.
Tipos según cómo se diseña la interfaz
Hay más formas de organizar una API.
REST
Recursos y operaciones
Consultar perfiles e inventariosGraphQL
Pides campos concretos
Armar una pantalla con varios datosRPC / gRPC
Llamas una operación definida
Comunicar servicios con contratos y mensajes tipadosSOAP
Mensajes XML con reglas formales
Integraciones empresariales y sistemas existentesEs un mapa de opciones. No hay una ganadora universal. REST, GraphQL y gRPC no describen quién tiene acceso.
GraphQL · Mira la forma de la respuesta
Elige los campos que necesita tu pantalla.
Marca apodo, nivel o partidas y observa la consulta.
Mi pantalla necesita
Selecciona al menos un campo.
{ jugador { apodo nivel } }{ "data": { "jugador": { "apodo": "Luna", "nivel": 12 } } }Ejemplo ilustrativo. El servidor ofrece un esquema y controla permisos y coste; no da acceso directo a la base.
Tipos según cuándo y en qué dirección hablan
¿Pregunto cada vez o dejo una conexión abierta?
Dibuja el recorrido de los mensajes, no sólo su nombre.
Polling es un patrón. WebSocket es un protocolo. SSE usa HTTP. Estas opciones pueden complementar una API REST.
Prueba las direcciones
Un grupo recibe un aviso.
Cambia el canal y prueba qué mensajes pueden circular por él.
Tu pantalla
Una conexión puede llevar mensajes en ambas direcciones.
0 mensajesEl servidor
Simulación de mensajes. No abre una conexión de juego ni un WebSocket real.
Una distinción que importa
Consultar tu historial y mover a tu personaje tienen necesidades distintas.
La API de estadísticas y la comunicación de la partida no hacen el mismo trabajo.
Una consulta cuando la necesitas
Una solicitud y una respuesta pueden bastar para abrir una pantalla.
Mensajes frecuentes y validación del mundo
Movimiento, entradas del jugador y estado del mundo tienen otros requisitos.
Riot describe un servidor autoritativo para VALORANT y tráfico de juego con requisitos de red distintos. No todos los mensajes de un juego pasan por REST.
Webhook · Un servicio avisa a otro
Terminó la partida. Te mando el resultado.
La Tournament API de LoL puede enviar un aviso HTTP POST al servidor de un torneo registrado.
Servicio del juego
Finaliza la partida
Callback del torneo
URL del organizador
Servidor del torneo
Procesa el resultado
Tabla del torneo
Actualiza resultados
Termina una partida creada mediante el sistema de códigos de torneo.
Un webhook avisa a un servidor. Para actualizar el navegador puedes usar polling, SSE u otro canal.
Actividad 03 · Elige y explica
El mensaje cambia. El canal también puede cambiar.
Una web sólo recibe un marcador que se actualiza.
Conecta con frontend, backend y datos
La web muestra. El backend decide. La base guarda.
La API define cómo se comunican el cliente y el servicio.
Frontend
Pantalla y acciones
API del backend
Rutas y contrato
Backend
Reglas y permisos
Base de datos
Datos guardados
La persona abre la página del inventario.
La API forma parte de la interfaz del backend; no siempre es otro servidor separado.
Dos preguntas diferentes
¿Quién eres? ¿Qué puedes hacer?
La sesión responde la primera. Las reglas del servidor responden la segunda.
PATCH /api/inventario/i1El objeto i1 pertenece a Luna.
La selección representa una identidad ya validada en esta simulación.
Prueba una identidad.
El método y la ruta no bastan para conceder un permiso.
HTTPS protege el viaje. Validar datos y permisos sigue siendo necesario. CORS no sustituye la autenticación.
Conecta con la clase de bases de datos
Consultar otra vez puede costar menos trabajo.
Una caché conserva una copia. Cuando el dato cambia, hay que mantenerla al día.
Primero leemos los datos. Luego podemos reutilizar una copia.
Si el servicio limita las solicitudes, respeta la espera indicada y reduce los intentos.
Tiempos ilustrativos de un modelo de clase, no mediciones de Fortnite, Riot ni de esta computadora.
Laboratorio · 8 minutos
Tú mandas la solicitud.
Cambia el método, la ruta o los datos. Mira la respuesta y el inventario.
Respuesta
Envía la primera solicitud.
- La traza mostrará el recorrido.
Datos simulados
Vista didáctica del servidor. El JSON sólo devuelve los datos permitidos para la sesión.
Simulador local con datos ficticios. Las solicitudes se procesan en este navegador y no se envían a los juegos.
Frontend · El código que pide y dibuja
fetch envía. Tu interfaz decide qué mostrar.
async function cargarInventario() {
try {
const respuesta = await fetch("/api/inventario");
if (!respuesta.ok) {
throw new Error(`HTTP ${respuesta.status}`);
}
const datos = await respuesta.json();
mostrarObjetos(datos.objetos);
} catch (error) {
mostrarError(error.message);
}
}- 01
Pide una ruta del mismo sitio.
- 02
Comprueba el estado HTTP.
- 03
Convierte JSON en datos.
- 04
Actualiza la pantalla o muestra el error.
Código de ejemplo para una app con backend. No llama un servicio de juego desde esta presentación.
Backend y base de datos
Validar, consultar y responder.
async function leerInventario(req) {
const usuario = await autenticar(req);
if (!usuario) return json(401, { error: "Inicia sesión" });
const objetos = await db.query(
"SELECT id, nombre, cantidad FROM inventario WHERE propietario = ?",
[usuario.id]
);
return json(200, { objetos });
}- 01
La identidad viene de una sesión validada.
- 02
La consulta filtra por esa identidad.
- 03
El parámetro se envía separado del SQL.
- 04
El backend devuelve los datos permitidos.
Pseudocódigo. autenticar, db.query y json dependen del framework y del driver; ? es un marcador ilustrativo.
Actividad 04 · En parejas
Diseñen una web para su escuadrón.
En dos minutos, expliquen el recorrido de un mensaje.
01¿Qué muestra el frontend?
02¿Qué solicitud envía?
03¿Qué permiso comprueba el backend?
04¿Qué guarda la base de datos?
05¿Cómo se entera el resto del grupo?
Ejemplo. La pantalla muestra una sala. PATCH /api/salas/s1/mi-estado cambia mi estado. El backend valida que pertenezco a la sala. Guarda listo=true y avisa por un canal apropiado.
Antes de salir · 4 minutos
Explícalo con tus palabras.
¿Qué define una API?
Ya puedes seguir el mensaje
Detrás de cada acción, busca el acuerdo.
Qué pido. Cómo lo pido. Qué puede pasar.
La persona actúa.
El frontend prepara un mensaje.
El servicio responde.
El backend valida y hace el trabajo.
La pantalla cambia.
El frontend usa los datos recibidos.
Siguiente paso de práctica. Construir un frontend pequeño que consuma una API de clase.
Para consultar después
Documentación y alcance de los ejemplos.
Fuentes primarias revisadas para esta clase. Los datos y endpoints /api de práctica son nuestros.