Cuando un equipo de integración elige el formato de servicio para un nuevo conector, la conversación suele girar en torno a REST, GraphQL o mensajería asíncrona. Pero la decisión real casi nunca es técnica: depende del volumen de datos, de quién consume el endpoint y de cuánto margen de error tolera el negocio. En este post reviso los criterios que usamos en el foro para orientar esa elección sin caer en dogmas.
El primer filtro es el patrón de consumo. Si el cliente necesita respuestas inmediatas y consultas puntuales, un endpoint REST con paginación clara suele ser suficiente. Si el consumidor procesa lotes o eventos continuos, un tópico de mensajería con reintentos y dead-letter queue evita que un pico de tráfico sature la base de datos. No hay formato superior; hay un formato que encaja con el flujo real.
El segundo filtro es la evolución del esquema. En entornos productivos, cambiar un campo obligatorio a opcional puede romper consumidores que no fueron actualizados. Por eso recomendamos versionar el contrato desde el primer día, documentar los cambios en el changelog y probar la compatibilidad hacia atrás antes de cada despliegue. Un formato flexible no reemplaza una buena disciplina de versionado.
El tercer filtro es la capacidad del equipo para operar lo que elige. Un formato sofisticado con validación de esquemas y transformaciones complejas exige monitoreo y herramientas de depuración. Si el equipo no tiene presupuesto para mantener esa infraestructura, un enfoque más simple con logs claros y métricas básicas puede rendir mejor. La complejidad solo se justifica cuando resuelve un problema concreto.
En el foro hemos visto incidentes que no fueron causados por el formato en sí, sino por una elección que no consideró el contexto operativo. Antes de decidir, conviene responder tres preguntas: quién consume el servicio, con qué frecuencia y qué pasa si falla. Con esas respuestas, la discusión técnica se vuelve mucho más simple.