Structured applications using REST and FSMs

1   Introduction

In previous posts in this Blog, we have, separately, considered REST and FSMs (finite state machines) and have described how to implement them.

Now perhaps, it's a good time to think about what those two application styles might be good for, how they can be combined into a larger, more complex application structure, and what the benefits might be of doing so.

I this line of thinking, I'm a little bit inspired by the way in which Erlang processes can be combined to produce a larger application, and especially the way in which, following the OTP guidelines, some of those processes can be supervised so as to produce a more robust application which survives "soft failures".

2   Options -- Some possible application structures

We need some possible ways to organize and structure our composite application. Here are a few:

  1. An FSM "on top" with a REST back-end -- The REST back-end manages the objects/resources that are tracked by the FSM/work-flow. The FSM implements the work-flow. The FSM talks to the REST server; the REST server manages the resource objects.
  2. A REST server that uses an FSM to manage the work-flow for the resources that it managers. The FSM operates in the back-end, that is underneath the REST server. The client interacts with the REST server; the REST server interacts with the FSM.

The remainder of this document will look at the first of the above (FSM/work-flow on top, REST back-end), in part because we want to give the client more power to design and control the processing of her/his documents and resources.

Implementation -- There are many ways to implement this configuration. We'll be looking at the following:

  • FSM:
    • Erlang gen_statem -- This Erlang module is a behavior, i.e. it enables us to take a good deal of boiler-plate and add a bit in the way of call-back functions to implement an FSM.
    • Python transitions -- We've seen this in a previous post at this site (). This Python module makes it straight forward to create rule-based FSMs.
  • REST:
    • Erlang Cowboy -- Cowboy is a Web server implemented in and for Erlang. It provides the logic behind the Erlang REST behavior. In order to implement a REST server with Cowboy, we implement a module that implements call-back functions in support of the REST features we wish to implement, as described in the REST section of the Cowboy User Guide.
    • Python Flask and the flask-restful extension -- See Flask RESTful documentation.

3   A client-oriented goal

If the FSM is on the client side and implements the client's work-flow, we'd like the client to be able to define that work-flow as easily as possible and to do so in an implementation independent way. Possibly, we'd be able to generate the implementation in one or more specific languages (e.g. Python and Erlang) from the client's specification.

Both gen_statem for Erlang and transitions for Python should make this possible.

[to be continued]