Question

I’ve built a RESTful service for the Data Access Layer (DAL) of my architecture:

POST http://example.com/data/User
GET|PUT|DELETE http://example.com/data/User/{UserId}

However, for the Business Logic Layer (BLL), a second non-RESTful service is used:

POST http://example.com/accountapi/register
POST http://example.com/accountapi/login

This BLL service, instead of making calls to the DAL service, it talks directly to the database.

How would you improve this architecture?

1. Should the BLL service call the DAL service ?
2. Should I drop the DAL service and only expose the BLL service ?
3. Should I, somehow, inject business logic on my RESTful DAL service ? If yes, how ?

Answer 1

(1) Avoid having your (non-REST) web service business logic layer make further (RESTful) HTTP requests onto the data access layer. Doing so of course would be less efficient than making direct method calls. But much more importantly, it would require you to deploy the BLL web services and the DAL web services onto separate web server instances (or separate clusters). Otherwise you can have a case where all your HTTP worker threads are busy trying to serve up BLL responses, and each is blocked waiting fruitlessly for a free HTTP worker thread to serve it a DAL response. This can lead to stalls (if you do timeout/retry processing) or outright deadlocks (if you don’t).

(2 and 3) If your web service clients need both business logic and data access, provide those as a unified set of services. Internally they both depend on the same data access layer method calls: it’s just that the data oriented web service implementations make just one data access layer call while the business logic oriented web service implementations may make many DAL calls. You do most definitely want to structure the BLL and DAL layers separately beneath the web service layer though.

I like to think of the web services as just the part of the presentation layer oriented towards “users” who happen to be other programs.