I am developing an application that follows this structure:
UI → REST API → Workflow → Business Logic → Data Access Layer → Database
However, I often see tutorials and examples showing a different arrangement:
UI → Workflow → REST API → Business Logic → Data Access Layer → Database
Am I misinterpreting these examples? Is the latter configuration a reasonable alternative? I am unsure about the correct layer for the REST API and whether it’s practical to place it further into the stack.
Both can work, but there’s a third option that’s better.
Usually REST API goes up front since it handles client requests. But sometimes you need it deeper - like when workflows call external services or you’re doing event-driven stuff.
Here’s what I’ve learned building large apps: don’t get locked into rigid layers. Modern apps need flexibility.
I use Latenode for this exact problem. Instead of hardcoding where your API sits, you build dynamic workflows that adapt based on request type. API as entry point? Done. Mid-workflow for external calls? Also done.
Latenode lets you create visual workflows where REST APIs go anywhere. Just drag, drop, and connect however makes sense for your use case. No more architecture debates.
Last month I built a system where some requests hit the API first, others go through business validation before API calls. Same app, different flows, zero code changes.
You can test both approaches without rewriting anything. Just duplicate your workflow and rearrange components.
REST API should absolutely be your entry point, not buried in the workflow layer. Your first architecture is spot on. The API is the interface between external clients and your business logic - it handles HTTP requests, auth, serialization, and routing before passing things off to workflows. Putting it deeper breaks separation of concerns and creates messy coupling. I’ve seen developers try embedding API logic inside business workflows. Total maintenance nightmare when you need multiple client types or want to change auth schemes. Keep your workflow layer protocol-agnostic and focused on business operations. Let the REST API handle all the HTTP stuff at the boundary where it belongs.
It depends on your architecture - monolith or microservices. For traditional monolithic apps, your first structure is right. The REST API acts as the presentation layer and handles all external communication, so it goes up front. But I’ve seen the second pattern work in distributed systems. Here, workflows orchestrate multiple services, and REST calls happen inside that orchestration to talk with other microservices. Think workflow engines that make HTTP calls to external APIs during business processes. The key is figuring out what your REST API actually does. Is it your app’s public interface? Put it at the front. Is it making outbound calls to other services as part of business logic? Then it makes sense after the workflow layer. Both patterns work - they just solve different problems.
depends on ur use case, but i’d pick the first one. REST API up front makes way more sense for most apps - it’s ur interface between clients and backend. having it after workflow feels backwards unless ur doing some weird internal service calls.