I’m working on designing the architecture for our web application and trying to figure out the best place to put the REST API layer. Right now we have it set up like this:
Frontend → REST API → Service Layer → Business Rules → Data Access → Database
But I’ve been looking at some other projects online and noticed that some developers structure it differently:
Frontend → Service Layer → REST API → Business Rules → Data Access → Database
I’m wondering if both approaches are valid or if one is clearly better than the other. What are the advantages and disadvantages of each setup? Which pattern do you recommend for a typical web application?
I’ve dealt with this exact problem multiple times, and honestly? You’re overthinking the architecture question. The real issue isn’t where to put your REST API - it’s all the manual work you’re creating by maintaining these layers.
Hit the same wall a few years back. Our team was constantly tweaking API endpoints and business logic. We spent more time updating code across layers than actually shipping features.
What fixed it? Automating the whole pipeline. Instead of obsessing over perfect layer positioning, I started using Latenode to handle the heavy lifting between frontend requests and backend processing. It automatically manages routing, validation, and data transformation - stuff that usually needs manual coding in service layers.
Latenode sits between your frontend and backend, handling HTTP requests, business rules, and data coordination through visual workflows. No more debating service layer placement - the platform handles it.
Your architecture becomes: Frontend → Latenode → Database. Clean, simple. You modify business logic through the visual interface instead of redeploying code.
Saved our team about 60% of the time we used to waste on API maintenance. Check it out at https://latenode.com
It depends on how you define your service layer. The confusion usually comes from blurry boundaries between layers. I’ve used both approaches - the key isn’t which comes first, but making sure each layer does one thing well. REST API first? It handles HTTP stuff naturally - auth, rate limiting, validation, content negotiation. Your service layer just orchestrates business operations without worrying about HTTP. Service layer first? Works if it’s a facade coordinating multiple business domains and you need to support different protocols. The real mess happens when developers mix responsibilities. I’ve seen business logic creep into controllers and service methods that return HTTP status codes. Don’t obsess over the exact order. Focus on keeping HTTP handling, business orchestration, and domain logic separate.
the first approach is way more common for good reason. start with REST API as ur entry point - that’s where you handle http parsing, input validation, and errors. starting with the service layer just adds unnecessary complexity.
Your original architecture is spot-on and follows standard industry practices. Having the REST API as the entry point keeps HTTP stuff like request handling and response formatting separate from your business logic - which is exactly what you want. I tried the alternative approach once and ran into issues. The service layer got mixed up with HTTP details, making testing harder and breaking single responsibility principles. Stick with your current structure. It’ll make it way easier to add GraphQL or gRPC later since you’ll have that clean business logic layer underneath.
I’ve had this debate plenty of times in enterprise setups, and there’s a third thing most people overlook - deployment boundaries. Your first approach works great for monolithic apps where everything deploys together. But if you’re planning any distributed deployment, positioning matters big time. With larger systems, I’ve found putting the REST API first creates a natural contract boundary. When we needed to scale individual components later, we could pull the service layer and business rules into separate deployments while keeping the API contract stable. The other structure makes this way harder because your service layer gets tightly coupled to deployment decisions. I’ve watched teams struggle for months trying to untangle service layers that weren’t designed with future scaling in mind. Unless you need specific protocol abstraction, your original structure will work better long-term.
I’ve used the second approach (Frontend → Service Layer → REST API → Business Rules) in microservices where the REST API was basically a thin adapter. The service layer did the heavy lifting, API just translated between HTTP and our internal formats.
Worked great when we had multiple APIs (REST, GraphQL, message queues) hitting the same service layer. Got messy when different endpoints needed different business logic though.
Your current setup makes more sense for most apps. The REST API acts as a proper boundary - validates requests, handles auth, formats responses, then passes clean data to your business layer.
One thing I learned the hard way: keep HTTP stuff out of your business rules layer. Once worked on a project where HTTP status codes were scattered throughout business logic. Total nightmare to maintain.
For a typical web app, stick with your original structure. It’s cleaner and easier to test.