¿REST API es siempre adecuado para la industria? ¿Cuándo conviene optar por colas, brokers y comunicación orientada a eventos?

La pregunta de si una REST API es adecuada para la industria ya no es hoy un debate sobre el estilo de integración preferido, sino una decisión sobre dónde asumirá el proyecto el coste, la latencia y la responsabilidad operativa. En un entorno industrial, la interfaz de comunicación deja muy pronto de ser una «capa técnica» para pasar a influir en la continuidad del proceso, la trazabilidad de las acciones, la posibilidad de auditoría y la forma de responder ante fallos. REST funciona bien cuando se espera una llamada simple, una respuesta inequívoca y un control claro del estado de la solicitud. El problema aparece cuando el sistema debe seguir funcionando pese a la indisponibilidad temporal de alguno de los participantes, cuando los mensajes tienen que entregarse con confirmación o cuando un único evento debe producir efectos en varias áreas independientes. En ese momento, la elección entre una solicitud síncrona y una cola, un broker y una comunicación basada en eventos deja de ser técnicamente neutra.

Esto es especialmente relevante ahora, porque cada vez más proyectos industriales conectan el control, el mantenimiento, los sistemas de calidad, la notificación de producción y los servicios externos en una sola cadena de dependencias. Si la arquitectura se basa exclusivamente en llamadas síncronas, el equipo suele recibir un sistema aparentemente simple, pero frágil cuando aumenta el número de integraciones, cuando la red es inestable o cuando se exige una trazabilidad estricta de los eventos. El coste de esa decisión no se hace visible en la fase de demostración funcional, sino más tarde: en procesos bloqueados por un componente no disponible, en la dificultad para reconstruir la secuencia de un incidente, en la conciliación manual de estados entre sistemas y en las discusiones sobre si una operación se ejecutó realmente o solo se ordenó. Para el propietario del producto y el jefe de proyecto, el criterio práctico es sencillo: hay que decidir si un determinado intercambio de datos responde al modelo «pregunta–respuesta aquí y ahora» o más bien al de «registrar un hecho y garantizar su tratamiento posterior incluso en caso de perturbaciones». De esa respuesta depende no solo la tecnología, sino también el modelo de responsabilidades entre equipos.

En la práctica, esto se aprecia claramente en los sistemas de máquinas, donde una sola acción del operario o un único evento de proceso debe registrarse, transmitirse y confirmarse en varios puntos. Si la aplicación de supervisión envía una solicitud síncrona a servicios sucesivos y espera a recibir todas las respuestas, un problema momentáneo en uno de los elementos puede detener toda la secuencia, aunque parte de los efectos de negocio deberían producirse de forma independiente. En cambio, un broker o una cola permiten separar el momento de recepción de la información del momento de su procesamiento, conservar la traza del evento y controlar con mayor facilidad los reintentos tras un error. Esto no significa que la comunicación basada en eventos sea siempre mejor: si se necesita una decisión inmediata que bloquee el movimiento posterior de la máquina o el operario debe recibir al instante una respuesta vinculante, un modelo asíncrono sin estados intermedios bien diseñados puede aumentar la incertidumbre. Por eso, ya desde el inicio del proyecto conviene medir no solo el tiempo de respuesta, sino también el número de mensajes perdidos o duplicados, el tiempo necesario para conciliar estados discrepantes y la posibilidad de reconstruir la secuencia de eventos después de un incidente.

Este aspecto se relaciona de forma natural con la evaluación del riesgo en proyectos industriales, porque la elección del modo de comunicación influye en las consecuencias del error, en la detectabilidad de las anomalías y en la posibilidad de implantar medidas eficaces de reducción del riesgo. Si a través de la interfaz pasan funciones cuya ejecución incorrecta puede provocar una puesta en marcha no intencionada, un cambio de estado peligroso o la pérdida de control sobre la energía, el asunto deja de ser exclusivamente informático y pasa al ámbito del diseño del sistema de la máquina y de la evaluación de las medidas de protección. En ese punto aparece también el límite a partir del cual deben analizarse cuestiones relacionadas, entre ellas la protección frente a la puesta en marcha inesperada y la evaluación del riesgo según ISO 12100 conforme a la metodología adoptada. En otras palabras: la decisión entre REST, una cola o un broker no debería tomarse después de una demo de integración, sino cuando el equipo es capaz de definir qué consecuencias tiene para el proceso, la seguridad y la trazabilidad operativa un mensaje erróneo o retrasado.

Dónde suelen aumentar el coste o el riesgo

La mayoría de las decisiones erróneas no se deben a elegir una «tecnología equivocada», sino a asignar una REST API a tareas para las que no fue diseñada. En la industria, el coste aumenta cuando una interfaz de solicitud–respuesta debe soportar una comunicación sensible a la indisponibilidad momentánea, al orden de los eventos o a la necesidad de una confirmación fiable de la ejecución. Si el sistema solo tiene que leer el estado actual de un equipo o aceptar una orden cuya ausencia puede detectarse fácilmente y repetirse sin efectos secundarios, REST puede ser suficiente. Sin embargo, si el resultado depende de que el mensaje llegue exactamente una vez, en el orden correcto y con posibilidad de reconstruir el historial tras un incidente, el coste de compensar las limitaciones de REST supera rápidamente la aparente simplicidad de la implantación. En la práctica, esto implica lógica adicional de reintentos, mecanismos propios de almacenamiento temporal, conciliación de estados divergentes y una atribución de responsabilidades más compleja cuando el equipo ejecutó la operación más tarde de lo esperado o la ejecutó dos veces.

En la fase de diseño, el problema suele parecer inofensivo: el equipo da por supuesta una red estable, la disponibilidad constante de los servicios y un estado inequívoco en ambos lados de la integración. En el entorno industrial, estas premisas rara vez se mantienen durante mucho tiempo. Aparecen cortes de comunicación, reinicios de equipos, actualizaciones del sistema intermedio y, a veces, simplemente una sobrecarga durante el cambio de turno de producción. En ese momento, una arquitectura basada exclusivamente en llamadas síncronas empieza a trasladar el riesgo a las aplicaciones y a los operadores. El coste del proyecto aumenta no solo por las correcciones de software, sino también por las pruebas de recuperación, los procedimientos operativos adicionales y las discusiones sobre qué parte «debería haber sabido» que la solicitud no se había ejecutado. El criterio práctico para decidir es sencillo: si la indisponibilidad del receptor no puede detener al emisor, y el mensaje debe conservarse de forma segura y procesarse más tarde, conviene plantearse seriamente una cola, un broker o una comunicación orientada a eventos en lugar de un REST puro.

Un buen ejemplo es la integración de un sistema de supervisión con una línea en la que un sistema ordena un cambio de receta, y varios otros deben recibir ese cambio, confirmarlo y aplicarlo en el momento adecuado del ciclo. Con REST es fácil construir una llamada de «establecer parámetros», pero es más difícil garantizar que todos los elementos implicados hayan recibido la misma información, que un mensaje antiguo no sobrescriba uno más reciente y que, tras un fallo, pueda determinarse quién vio qué instrucción. Un broker de eventos o una cola ordenan este problema de otra manera: el mensaje pasa a ser un hecho persistente dentro del sistema, trazable, reprocesable y disponible para que varios receptores lo consuman de forma independiente. No se trata de una elección exclusivamente técnica. De ella depende que, ante una reclamación de lote, una parada o un incidente, pueda demostrarse cómo se desarrolló la toma de decisiones del sistema y, por tanto, también atribuir la responsabilidad contractual, operativa o interna. Allí donde la trazabilidad y la rendición de cuentas son importantes, conviene medir no solo la latencia de respuesta, sino también el número de mensajes que requieren reintento, el tiempo necesario para reconciliar el estado tras un fallo y la posibilidad de reconstruir la secuencia de eventos sin tener que hacerlo manualmente a partir de múltiples registros.

Esta cuestión entra en el ámbito de la evaluación del riesgo según ISO 12100 cuando un mensaje erróneo o tardío puede modificar el comportamiento de una máquina, de un proceso o de una medida de protección. En ese caso, ya no basta con preguntarse por la comodidad de la integración; hay que evaluar el efecto, la detectabilidad y la posibilidad de limitar las consecuencias, en línea con la práctica conocida de ISO 12100. Si la comunicación afecta a funciones relacionadas con la seguridad, enclavamientos, condiciones de arranque o confirmaciones del estado de la energía, el límite de la responsabilidad de diseño deja de estar en el nivel de la aplicación y pasa al nivel del sistema completo de la máquina. Del mismo modo, en los sistemas de accionamiento, también los hidráulicos, una suposición errónea sobre la entrega puntual de la información puede entrar en conflicto con los principios de diseño de las medidas de protección y de los estados seguros, lo que conduce de forma natural a cuestiones asociadas con UNE-EN ISO 4413. En otras palabras, las colas y los brokers no son «mejores por definición», pero sí se convierten en la opción adecuada allí donde el diseño debe soportar un fallo de comunicación sin perder el control, el historial ni la responsabilidad sobre las acciones ejecutadas.

Cómo abordar el tema en la práctica

En la práctica, la pregunta no es si una API REST es buena o mala, sino si encaja con las consecuencias de un error, de un retraso y de la falta de respuesta en un proceso industrial concreto. Si la comunicación sirve principalmente para leer datos, iniciar tareas administrativas o integrarse con sistemas de negocio, una interfaz de solicitud–respuesta puede ser la solución más simple y económica. El problema empieza cuando el diseño exige continuidad en el intercambio de información pese a la indisponibilidad temporal de una de las partes, la necesidad de procesar los eventos de forma ordenada o la obligación de reconstruir quién, cuándo y sobre qué base provocó un determinado cambio de estado. En ese escenario, elegir REST como mecanismo por defecto suele reducir el coste de entrada, pero eleva el coste de gestionar fallos, reconciliar el estado tras una interrupción y aclarar un incidente. Ese es el momento en que las colas, los brokers y la comunicación orientada a eventos dejan de ser un «complemento arquitectónico» y pasan a ser una herramienta para limitar el riesgo de diseño y la responsabilidad operativa.

Para el equipo y el manager, esto implica tomar una decisión arquitectónica basándose en varias características medibles del proceso, y no en las preferencias del proveedor. El criterio más útil es simple: hay que definir qué debe ocurrir con el mensaje cuando el receptor no responde en el momento del envío. Si la respuesta correcta es «nada crítico, la operación puede repetirse o descartarse con seguridad», REST suele ser suficiente. En cambio, si el mensaje debe conservarse, entregarse al reanudarse la operación, procesarse una sola vez o en un orden demostrable, entonces la arquitectura síncrona empieza a dejar de ajustarse a los requisitos del proceso. Conviene dejarlo ya por escrito en la fase de definición como criterios de aceptación: tiempo admisible de indisponibilidad del sistema contraparte, forma de reintento, reglas de deduplicación, posibilidad de trazar la correlación entre eventos y modo de reconstruir el estado tras un fallo. Sin este tipo de acuerdos, el proyecto aparentemente arranca más rápido, pero después regresa en forma de cambios de integración costosos, disputas sobre el alcance de la responsabilidad e incidencias operativas difíciles de cerrar.

Un buen ejemplo es una línea o una célula en la que el sistema de nivel superior envía órdenes, y los controladores y puestos informan de la ejecución, los rechazos, los bloqueos o los cambios entre modos de funcionamiento. Si cada evento se «consulta» de inmediato mediante REST, una pérdida momentánea de conectividad genera muy rápidamente una discrepancia entre el estado real y el estado visible en la aplicación. Desde la perspectiva de producción, esto acaba en conciliaciones manuales; desde la perspectiva de calidad, en lagunas en el historial del lote; y desde la perspectiva del mantenimiento, en la incertidumbre de si una orden concreta se ejecutó realmente o solo se envió. Un broker con almacenamiento persistente de mensajes no lo resuelve todo, pero sí ordena las responsabilidades: el emisor entregó el evento, el sistema intermedio lo conservó y el receptor lo confirmó o no. Esta diferencia es fundamental al analizar las causas de una parada y al determinar si el error se debió a la lógica del proceso, a un fallo de red o a una secuencia incorrecta de acciones del operario. Precisamente por eso, la decisión sobre el modelo de comunicación influye no solo en el coste de implantación, sino también en el tiempo de puesta en marcha, servicio y auditoría.

Esta cuestión entra en el terreno de la evaluación práctica del riesgo cuando el mensaje deja de ser solo información y pasa a ser una condición para el funcionamiento de la máquina, del proceso o de una medida de protección. Si la posibilidad de arrancar, reanudar el trabajo tras una parada, desbloquear una secuencia o confirmar un estado seguro de la energía depende de la transmisión correcta del estado, la decisión de integración pasa a formar parte de una decisión de diseño de mayor alcance. En ese caso, no solo hay que evaluar la disponibilidad de la comunicación, sino también las consecuencias de su pérdida, retraso, duplicación o interpretación errónea; aquí aparece de forma natural la metodología conocida por la evaluación del riesgo según ISO 12100. A su vez, allí donde la comunicación afecta a las condiciones para prevenir una puesta en marcha inesperada, no debe tratarse la capa de información como sustituto de las soluciones previstas para el corte de energía y el estado seguro. Ese es el límite a partir del cual el tema ya se relaciona con el análisis de la protección frente a la puesta en marcha inesperada y, en un sentido más amplio, con el diseño del sistema de la máquina más allá de la mera funcionalidad. En otras palabras, REST es válido para la industria cuando el proceso acepta conscientemente sus limitaciones; cuando no es así, los mecanismos de colas y la comunicación orientada a eventos resultan más adecuados, porque responden mejor a los requisitos de continuidad, trazabilidad y control de las consecuencias de los fallos.

Qué tener en cuenta en la implantación

El error más frecuente en la implantación consiste en tratar la elección entre una API REST y una comunicación orientada a eventos como una decisión puramente técnica, cuando en la industria se trata de una decisión con consecuencias operativas y organizativas. REST no deja de funcionar por el hecho de entrar en una planta de producción, pero revela muy rápidamente sus limitaciones allí donde el sistema debe absorber interrupciones de conectividad, cargas irregulares, indisponibilidades temporales de servicios y la necesidad de reconstruir posteriormente la secuencia de eventos. Si la arquitectura parte de que cada respuesta debe llegar de inmediato y al primer intento, el proyecto se vuelve frágil. La consecuencia suele ser previsible: aumenta el coste de integración, se multiplican los mecanismos de contingencia y la responsabilidad por un estado incorrecto del proceso se diluye entre los proveedores de los sistemas. Por su parte, las colas y los brokers tampoco resuelven el problema de forma automática; introducen sus propios riesgos, como el procesamiento diferido, la duplicación de mensajes, la necesidad de ordenar secuencias y una supervisión más compleja. Por tanto, la pregunta no es si REST siempre sirve para la industria, sino si un proceso concreto tolera las características de esta forma de comunicación sin trasladar el riesgo a producción, mantenimiento y conformidad.

En la fase de diseño conviene adoptar un criterio de evaluación sencillo: qué ocurrirá exactamente con el proceso si el mensaje no llega, llega dos veces o llega tarde. Si la única consecuencia es una actualización tardía de los datos en el sistema de informes, REST puede ser suficiente. Sin embargo, si la falta de respuesta bloquea una secuencia, obliga a una intervención manual, provoca la pérdida del historial de ejecución de una operación o dificulta determinar quién tomó una decisión y con qué fundamento, entonces la arquitectura síncrona empieza a generar costes ya en la fase de puesta en marcha. En esa situación, una comunicación basada en cola o en broker suele ordenar mejor las responsabilidades: el emisor confirma la entrega, el receptor procesa a su propio ritmo y el equipo puede observar acumulaciones, reintentos y errores. Para el jefe de proyecto, esto significa que debe medir no solo la disponibilidad del servicio, sino también indicadores como el tiempo de permanencia del mensaje en cola, el porcentaje de reintentos, el número de mensajes no conciliados y el tiempo necesario para reconstruir el historial de eventos tras un incidente.

En la práctica, el problema se manifiesta especialmente allí donde una misma integración empieza a desempeñar varias funciones a la vez. Por ejemplo: el sistema de nivel superior envía una orden a un puesto, recibe la confirmación de ejecución y, al mismo tiempo, registra un estado que condiciona el siguiente arranque de la línea. Mientras hablamos de intercambio de datos de negocio, un retraso de varios segundos puede ser aceptable. Pero si esa misma vía de comunicación empieza a influir en una decisión de ejecución dentro del proceso, deja de ser un complemento informático neutral. Entonces, una elección incorrecta del mecanismo no solo se traduce en el coste de las paradas, sino también en la responsabilidad sobre si el sistema reacciona de forma previsible ante la falta de conectividad, el reinicio del servicio o un mensaje duplicado. Ese es el momento en que el tema pasa de forma natural al ámbito del diseño del sistema de la máquina más allá de la mera funcionalidad: hay que decidir qué consecuencias de fallo pueden tolerarse y cuáles exigen quedar separadas de la capa de integración.

Este límite adquiere aún más importancia cuando la comunicación empieza a afectar a condiciones relacionadas con la seguridad funcional o con la evaluación de riesgos. Si el cumplimiento de una condición de estado seguro, la autorización para reanudar el funcionamiento, la confirmación de la desaparición de energía peligrosa u otra función con relevancia protectora dependen de una correcta intercambio de datos, no basta con aplicar buenas prácticas de integración. En ese caso, hay que determinar con claridad si el elemento analizado sigue siendo únicamente una capa informativa o si ya entra en el ámbito del diseño de elementos de sistemas de control responsables de funciones de seguridad. Es aquí donde surgen las preguntas pertinentes del ámbito de UNE-EN ISO 13849-1 y de la evaluación de riesgos según ISO 12100, pero solo después de definir la función y las consecuencias del fallo. Para el equipo, esto implica la obligación de separar lo que puede gestionarse mediante una cola, un broker o REST de aquello que no puede basarse exclusivamente en una comunicación de propósito general. Si este límite no se define desde el principio, el coste reaparece más adelante en forma de cambios de diseño, discrepancias en la recepción y una responsabilidad en la toma de decisiones difícil de justificar.