¿API REST o acceso directo a base de datos? Qué vía elegir para integrar sistemas
Los dos caminos clásicos para conectar sistemas empresariales y sus riesgos. Cuándo la API es la vía correcta, cuándo el acceso a base de datos es razonable y por qué escribir directamente en la BD de un ERP casi nunca lo es.
Respuesta corta
Si el sistema expone una API que cubre los datos que necesitas, usa la API, porque es un contrato estable que el fabricante mantiene. El acceso directo a base de datos es razonable para LEER de sistemas veteranos sin API, pero escribir directamente en la base de datos de un ERP es casi siempre mala idea: te saltas su lógica de negocio y puedes corromper datos. Y cuando ninguna vía llega sola, un servicio intermedio combina lo mejor de ambas.
Por qué esta decisión importa más de lo que parece
La vía de conexión determina tres cosas que se pagan durante años: qué se rompe cuando el sistema se actualiza, qué tan seguro es el acceso y quién te puede ayudar cuando algo falla. Elegir por comodidad inicial (“tengo el usuario de la base de datos, tiro por ahí”) es hipotecar la integración.
Vía 1. La API del sistema
Una API es un contrato. El fabricante define qué se puede pedir y cómo, y se compromete (más o menos) a mantenerlo entre versiones.
A favor
- Estabilidad. El esquema interno puede cambiar; el contrato de la API, en principio, no.
- Seguridad. Hay permisos definidos y tokens revocables, y no circulan credenciales de base de datos.
- Lógica de negocio incluida. Crear un pedido por la API dispara las validaciones y procesos del sistema, igual que si lo tecleara un usuario.
- Soporte. Cuando algo falla, el fabricante responde de su API; de tus queries directas, no.
En contra (la letra pequeña que descubres a mitad de proyecto)
- APIs incompletas. Muchas cubren el catálogo pero no las tarifas especiales, o los clientes pero no sus condiciones de pago. Verifícalo campo a campo ANTES de decidir.
- Límites de uso. Hay topes de peticiones por minuto que convierten una sincronización masiva en una noche entera.
- Licencias aparte. En varios ERPs, el módulo de API se paga.
- APIs “modernas” solo de nombre. Algunas son un volcado XML de 2009 con otro traje.
Cuándo elegirla. Siempre que exista y cubra los datos que necesitas con la frescura que necesitas. Es la vía por defecto.
Vía 2. Acceso directo a la base de datos
Consiste en conectarse a la base de datos del sistema y leer (o escribir) sus tablas.
A favor
- Acceso a todo. Si el dato existe, está ahí, sin esperar a que el fabricante lo exponga.
- Sin límites artificiales de peticiones ni licencias de API.
- A menudo es la única opción con sistemas veteranos que no exponen nada más.
En contra
- El esquema interno no es un contrato. Una actualización del sistema puede renombrar una tabla y romper tu integración sin previo aviso ni changelog.
- Escribir es jugar con fuego. La aplicación valida, calcula y encadena procesos cuando crea un registro; tu INSERT no. Un pedido metido a mano en las tablas puede quedar huérfano de todo lo que el sistema hace alrededor.
- Seguridad más delicada. Las credenciales de BD suelen tener acceso amplio y son difíciles de acotar.
- Rendimiento. Una query pesada tuya puede ralentizar el sistema a los usuarios.
Cuándo es razonable. Para lectura, con un sistema sin API, con queries cuidadosas y fuera de horas punta cuando el volumen lo pida. Es una vía legítima que usamos, con respeto.
Cuándo evitarla. Para escritura, salvo como último recurso absoluto. Y en ese caso, mejor mediante los mecanismos de importación que el propio sistema valide, como los ficheros de intercambio o las tablas intermedias oficiales que tienen muchos ERPs veteranos. En la práctica es una tercera vía, y más segura.
La tabla de decisión
| Criterio | API | BD directa (lectura) | BD directa (escritura) |
|---|---|---|---|
| Estabilidad ante actualizaciones | Alta | Baja | Baja |
| Seguridad / control de acceso | Alta | Media | Baja |
| Cobertura de datos | La que ofrezca | Total | Total |
| Respeta la lógica del sistema | Sí | n/a | No |
| Soporte del fabricante | Sí | No | No |
| Veredicto | Por defecto | Aceptable con criterio | Evitar |
Cuando ninguna vía llega sola: el servicio intermedio
En la práctica, lo habitual es combinar. La API para lo que la API cubre, la lectura de datos para lo que no y los ficheros de importación validados para escribir en el sistema veterano. Un servicio intermedio (middleware) centraliza esa mezcla y añade lo que ninguna vía trae de serie, como la validación antes de aplicar cambios, el registro de cada ejecución, los reintentos y los avisos cuando algo no cuadra. Es el enfoque que contamos en cómo integrar un ERP con una aplicación web.
Más que «¿API o base de datos?», la pregunta útil es «¿qué combinación necesita cada flujo de datos?». El stock puede ir por API, el histórico por lectura directa y los pedidos por el mecanismo de importación del ERP, todos dentro de la misma integración.
Checklist antes de decidir
- Inventaría qué expone cada sistema: API (y qué cubre en la práctica), acceso a BD, ficheros o tablas intermedias.
- Lista los datos y su sentido, es decir, qué viaja, hacia dónde y con qué frescura.
- Prueba la API contra tus datos reales antes de comprometerte, tanto la cobertura como los límites.
- Para cada escritura, busca la vía validada por el sistema destino.
- Decide qué pasa cuando falle, porque fallará. Registro, avisos y reintentos.
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Ingeniero informático y desarrollador de software para empresas, con más de una década construyendo sistemas de gestión, integraciones y aplicaciones. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.