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?
I am just getting exposed to what ReST really is now and hopefully I'm not way off base here, but as I understand it, the client should be responsible for choosing what states to transfer to (workflow), so yes I think #2 is definitely valid. In fact I'd be interested to know how you implement workflow in your ReST API.
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
REST is access to resources. The question is "What's a resource"? Most answers are that it's a pretty low-level piece of information.
A composite application or workflow depends on one or more resources.
It's hard to say that a resource depends on a workflow. Not imspossible. But hard.
When designing a RESTful interface, you've only got the CRUD rules available to you. The most common expectation is that the response is totally married to your request. When you POST an X, you expect that the only state change is to create a new X. Not create an X and and Y with an optional pair of Z's.
I'd suggest that your second alternative puts REST in a better context -- access to stateful objects.