API REST
Una API REST es un estilo arquitectónico para diseñar servicios web sobre HTTP, descrito por Roy Fielding en 2000. Expone datos y funciones como recursos identificados por URL, que el cliente consume con los métodos estándar de HTTP; una API que cumple sus restricciones se llama RESTful.
Qué es
REST (Representational State Transfer) no es un protocolo ni un estándar, sino un conjunto de restricciones de diseño. La idea central es modelar datos y funcionalidad como recursos —por ejemplo /usuarios, /pedidos o /productos—, cada uno identificado por una URL. El cliente actúa sobre esos recursos mediante los métodos estándar de HTTP: GET para leer, POST para crear, PUT para reemplazar, PATCH para modificar de forma parcial y DELETE para borrar. Las respuestas suelen viajar en JSON, y cada una incluye un código de estado HTTP que comunica el resultado (200 OK, error de cliente, error de servidor).
Su rasgo más distintivo en la práctica es que es sin estado (stateless): cada petición debe llevar toda la información necesaria para resolverse, incluida la autenticación. El servidor no guarda contexto entre peticiones. Por eso el acceso y los permisos no son un añadido, sino parte de cada llamada: viajan en las cabeceras como una API key o un token (OAuth 2.0, bearer token) que determina qué recursos puede leer o modificar quien llama. Los seis principios de REST son interfaz uniforme, cliente-servidor, sin estado, cacheable, sistema en capas y código bajo demanda (este último, opcional).
En analítica, la API REST es la vía principal de integración entre sistemas. Plataformas como Google Search Console, GA4, Bing o un CRM exponen sus métricas a través de endpoints REST con clave o token: es así como un panel o un almacén propio obtiene los datos de forma programática, sin exportes manuales. REST se impuso frente a SOAP —un protocolo XML más pesado— por su simplicidad y porque se apoya en las propias funciones de HTTP. Su límite conocido es el over-fetching: tiende a devolver más datos de los necesarios o a exigir varias llamadas, problema que tecnologías como GraphQL buscan resolver.
| Método | Acción |
|---|---|
| GET | Leer |
| POST | Crear |
| PUT | Actualizar |
| DELETE | Borrar |
Por qué importa
Entender el contrato de una API REST —qué recursos expone, con qué métodos, qué autenticación exige y qué límites de cuota aplica— es lo que permite construir mediciones reproducibles y automatizadas en analítica. Cuando los datos entran por endpoint en lugar de por exporte manual, la medición deja de depender de pasos a mano y se vuelve repetible: es el primer eslabón de un proceso ETL / pipelines de datos, que extrae de cada fuente, transforma y carga hacia un destino común. Sobre ese acceso programático se apoyan también la Automatización con n8n, que encadena llamadas a endpoints sin escribir un servicio entero, y el MCP · Model Context Protocol, que envuelve estas mismas APIs en herramientas que un Agente de IA y mesh de agentes puede invocar de forma estructurada. No es una garantía de nada: una API mal entendida (permisos insuficientes, cuota agotada, campos que cambian de versión) rompe la integración igual que cualquier otro eslabón. El valor está en conocer el contrato, no en suponerlo.
En profundidad
Los seis principios y qué hace RESTful a una API
Las seis restricciones de REST son: interfaz uniforme (recursos identificados por URL y manipulados con métodos estándar), cliente-servidor (separación de responsabilidades), sin estado (cada petición es autónoma), cacheable (las respuestas indican si pueden almacenarse), sistema en capas (puede haber proxies o cachés intermedios sin que el cliente lo note) y código bajo demanda (opcional: el servidor puede enviar código ejecutable). Una API que respeta estas restricciones se denomina RESTful; cumplir solo algunas es habitual en la práctica.
Métodos HTTP y códigos de estado en una petición
Una petición REST combina un método (GET, POST, PUT, PATCH, DELETE) con la URL de un recurso. GET solo lee; POST envía datos y suele crear o provocar un cambio; PUT reemplaza el recurso por completo; PATCH aplica una modificación parcial; DELETE lo elimina. La respuesta lleva un código de estado HTTP que resume el resultado —éxito, error del cliente o error del servidor— como parte del mensaje autodescriptivo de la interfaz uniforme.
| Método | Qué hace | Efecto sobre el recurso |
|---|---|---|
| GET | Lee / consulta | Ninguno: solo lectura |
| POST | Envía datos | Crea o provoca un cambio |
| PUT | Reemplaza | Sustituye el recurso por completo |
| PATCH | Modifica | Aplica un cambio parcial |
| DELETE | Elimina | Borra el recurso |
Autenticación stateless: API keys, tokens y OAuth 2.0
Como REST no guarda estado, la autorización viaja en cada petición, normalmente en las cabeceras. Los mecanismos habituales son la API key (una clave que identifica al cliente) y los tokens, como el bearer token emitido por un flujo OAuth 2.0. El token o la clave definen qué recursos puede leer o modificar quien llama. Su caducidad, su alcance (scopes) y los límites de cuota asociados condicionan directamente qué puede hacer una integración: es la misma capa de credenciales y permisos que gobierna la Integración de APIs y ERP cuando un sistema propio se conecta a un software de terceros.
| Mecanismo | Qué viaja en la petición | Qué define el acceso |
|---|---|---|
| API key | Clave que identifica al cliente en la cabecera | Cuota y permisos asociados a la clave |
| Bearer token | Token emitido tras un flujo OAuth 2.0 | Scopes (alcance) y caducidad del token |
| OAuth 2.0 | Flujo de autorización que emite el token | Recursos que el usuario consiente delegar |
API REST en analítica: cómo GSC y GA4 sirven datos
Las plataformas de analítica exponen sus métricas como endpoints REST protegidos por token. Google Search Console y la API de datos de Google Analytics 4 (GA4) entregan datos de búsqueda y de comportamiento mediante peticiones autenticadas, normalmente vía OAuth 2.0. Esto permite a un sistema propio recoger métricas de forma programática y reproducible, frente al exporte manual, y conectar varias fuentes en un mismo almacén —el destino típico es un Data warehouse (BigQuery) donde cruzar varias APIs. Cuando una plataforma no expone endpoint, la alternativa es el Web scraping y connectors, menos fiable porque depende de la estructura de la página y no de un contrato.
Qué observar
Las señales que importan.
Estilo, no protocolo
REST es un conjunto de restricciones de diseño, no un estándar; solo la API que las cumple es RESTful. Distinguirlo evita tratar como obligatorio lo que es una convención de diseño.
Sin estado: la autenticación viaja en cada petición
El servidor no guarda contexto entre llamadas. Cada petición lleva su propia credencial en las cabeceras, lo que explica por qué un token caducado o un permiso insuficiente rompe la integración en cualquier punto.
Cada método HTTP tiene una semántica fija
GET lee, POST crea, PUT reemplaza, PATCH modifica de forma parcial y DELETE borra. Respetar esa correspondencia es lo que hace predecible el comportamiento de un endpoint.
Códigos de estado como respuesta autodescriptiva
Cada respuesta incluye un código HTTP que comunica el resultado (200 OK, error de cliente, error de servidor). Es la señal primaria para diagnosticar si una llamada funcionó o por qué falló.
Over-fetching como límite estructural
Los endpoints REST tienden a devolver más datos de los necesarios o a exigir varias llamadas. Es un coste de diseño conocido, no un fallo, y el motivo por el que surgen alternativas como GraphQL.
Conceptos clave
El vocabulario del término.
- REST (Representational State Transfer)
- Estilo arquitectónico para servicios web sobre HTTP definido por Roy Fielding (2000). No es un protocolo ni un estándar, sino un conjunto de restricciones de diseño.
- RESTful
- Calificativo de la API que cumple las restricciones de REST. Es habitual que una API cumpla solo algunas de ellas.
- Recurso / Endpoint
- Unidad de datos o funcionalidad (p. ej. /usuarios, /pedidos/123) identificada por una URL sobre la que el cliente actúa mediante métodos HTTP.
- Stateless (sin estado)
- Propiedad por la que cada petición es independiente y contiene toda la información para resolverse, incluida la autenticación; el servidor no guarda contexto entre llamadas.
- Métodos HTTP
- Verbos estándar que indican la acción sobre un recurso: GET (leer), POST (crear), PUT (reemplazar), PATCH (modificar parcialmente), DELETE (borrar).
- Bearer token / OAuth 2.0
- Credencial que viaja en las cabeceras de cada petición para autorizar el acceso. OAuth 2.0 es el marco que emite tokens (bearer) con un alcance y una caducidad definidos.
- Over-fetching
- Tendencia de los endpoints REST a devolver más datos de los necesarios o a exigir varias llamadas; es el límite que tecnologías como GraphQL buscan resolver.
- SOAP
- Protocolo de servicios web basado en XML, anterior y más pesado que REST; este se impuso por su simplicidad y su apoyo en las funciones nativas de HTTP.
Dónde lo aplicamos
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Fuentes
- REST (Glosario) - MDN Web Docs
- HTTP request methods - MDN Web Docs
- REST Architectural Constraints (los 6 principios) - REST API Tutorial
- What is a REST API? - TechTarget
- Architectural Styles and the Design of Network-based Software Architectures (tesis doctoral, origen formal de REST) - Roy T. Fielding, UC Irvine · 2000
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.