Qué es y cómo funciona
Una API es la puerta por la que un programa pide datos u operaciones a otro. REST es un estilo para diseñarla apoyándose en cómo ya funciona la web. Cada cosa que gestiona el sistema, como un artículo, un cliente o un pedido, es un recurso con su propia dirección, y se actúa sobre ella con los verbos de HTTP: GET para leer, POST para crear, PUT o PATCH para modificar y DELETE para borrar.
Las respuestas llevan un código de estado que indica qué ha pasado, por ejemplo 200 para correcto, 404 si el recurso no existe o 401 si falta autenticación, y un cuerpo que normalmente es JSON. Cada petición lleva toda la información necesaria para entenderla, sin que el servidor tenga que recordar una conversación anterior.
Como se apoya en HTTP, aprovecha herramientas que ya existen: las lecturas con GET se pueden cachear en el navegador, en una CDN o en un proxy. Y casi cualquier lenguaje o plataforma puede consumirla, lo que explica su popularidad. WordPress, por ejemplo, incluye una API REST propia.
Por qué importa
Casi toda integración moderna pasa por una API: conectar la web con un CRM, una pasarela de pago, un CMS headless o una app móvil. Si está bien diseñada, es fácil de entender, de probar y de mantener, y un equipo nuevo puede incorporarse rápido. La posibilidad de cachear las lecturas permite además servir mucho tráfico sin sobrecargar el origen.
Su punto débil es la rigidez del formato de respuesta. Un endpoint devuelve una estructura fija, así que el cliente puede recibir campos que no usa o necesitar varias peticiones para reunir datos relacionados. En proyectos con muchas pantallas distintas, eso se nota. También exige disciplina para mantener la coherencia y versionar los cambios sin romper a quien ya la consume.
Un ejemplo
Una web de reservas necesita mostrar las clases disponibles y permitir apuntarse. El front hace una petición GET a la dirección de las clases para listarlas y otra POST a la de reservas para crear una. Si la plaza se agotó, la API responde con un código de error claro y un mensaje que la web muestra al usuario. El mismo servicio puede atender después a una app móvil sin cambios.
Errores y confusiones frecuentes
- Diseñar direcciones con verbos en lugar de recursos, como crearPedido o borrarUsuario, cuando HTTP ya aporta los verbos.
- Devolver siempre código 200, incluso cuando hay un error. Los clientes y las herramientas de monitorización dejan de poder distinguir qué ha fallado.
- No paginar los listados. Devolver miles de registros de golpe ralentiza la API y consume memoria del cliente.