yeiniel

El diseño de APIs siguiendo el estilo arquitectónico REST es tema de debate constante en la red. Existen innumerables publicaciones sobre el tema tanto post personales como artículos respaldados por organizaciones. Separar la paja del grano en este tema es difícil dado que la fuente canónica de información son documentos académicos. Me encantaría leer algo mas aterrizado a la práctica del mismo Roy Fielding pero respeto su compromiso con la comunidad y su incansable trabajo en los procesos de estandarización. En este post voy a compartir con ustedes mi propia aproximación al problema. La parte en negritas sería la descripción necesaria de la API. El caso de estudio para este post será la clásica aplicación de Cosas Por Hacer . Lo primero es modelar el recurso Cosa Por Hacer o Todo como se le conoce en Ingles. Aquí vamos a asumir que es algo tan simple como que tiene 2 atributos: el titulo y la bandera de completado. Lo segundo sería identificar las acciones y el posible flujo de...

Currently I am working on a development project of a Control System and am faced with the task of massive event processing of measurements for signaling alarm conditions (alarms that are activated when a certain value becomes above or below a certain level, etc.). This control system notifies the alarm processing component each of the measured variables (tags) and the component ​​must update the state machine of each of the alarms set in the control system. The problem I face is that we want the system as a whole to be scalable (we need to resize depending on the load to which it is submitted) and therefore in some scenarios the number of notifications to the component of alarm processing is such that exceeds its handling capacity so it is impossible for a single computing entity (task or process) of performing real-time processing. Given this scenario, I raised the possibility of horizontally scale the alarms processing component. But the problem of scaling alarm  proce...