We have just updated the API specification with two endpoints, which complement the
/events endpoint that we have recently presented. Together, the three endpoints provide the core functionality of the iFLUX model:
- events are notified via the
- rules are configured via the
/rulesendpoint and evaluated whenever a new event is reported
- actions are triggered via the
This endpoint is not implemented by the iFLUX middleware, but by action targets (iFLUX is a client and issues POST requests to the endpoint). As an example, consider an e-mail gateway. By implementing the
/actions endpoint, the gateway can be integrated in a system where an email is sent to users when specific events are reported to iFLUX.
This endpoint is used to configure the event-condition-action rules evaluated by iFLUX when events are reported. We will come back later at the implementation details, but we can already mention that our first implementation will rely on handlebar templates for computing action properties based on event properties.
As an example, consider a rule that states that whenever a new temperature event is notified, an email should be sent to inform a certain person. In this use case, the following iFLUX elements would be used:
a temperature event type, which would typically be defined by a location and a temperature properties.
an email notification action type, which would be defined by a recipient, a subject and a body properties.
a rule, which would trigger an email notification action whenever a temperature event is received. In this rule, we want to use the event properties to compute the action properties (e.g. the body should be something like “Temperature in [event.location] is now [event.temperature]”). Handlebars provide a way to specify these transformations.