Question

Our application is structured something like:

UI <–> REST API <–> Workflow <–> Business Logic <–> DAL <–> DB

However, I am seeing a few examples where it looks like people are doing

UI <–> Workflow <–> REST API <–> Business Logic <–> DAL <–> DB

Is this my imagination? Or is the second option considered a viable alternative?

Answer 1

It really is relative to what you mean workflow.

Hypermedia as the engine of application state will give you a directed graph of states/resources. It is not necessary that these graphs form a workflow (e.g have a specific start and end point). They may well form a cycle, have bidirectional links and whatnot. I assume this graph is somehow derrived from the business logic.

If you include your workflow (a specific path from one point to another via the graph) in you UI, you make some assumptions about the REST API therefore tightly coupling your UI with the business logic, therefore throwing the discoverability of REST away.

In general mixing workflows (imperative programming) with REST (declarative programming) is very problematic. The best approach would be to have an adaptive UI that can allow the user to navigate the network of states instead of constraining them through bespoke, predetermined workflows. That is how a browser works, anyways.

If you really need to have some workflows though, you could implement them by creating a chain of interconnected resources and guiding the user to the first one. In this sense, your first option would be valid although I find the seperation of business logic and workflow to be a grey area. Workflows are part of the business logic or, to state it better, are derrived from the business logic.

These opinions are my own, however a good, relevant article on the topic can be found here: http://www.infoq.com/articles/webber-rest-workflow