Layers to develop web service

Question

I am developing using REST (with Restfull API), where I think of using two layers in the system: BLL and DAL.

BLL => Would be the layer referring to business rules.

DAL => It would be the layer responsible for access to the data. It could be DAO as well, the latter being where the access through objects.

For a REST-style architecture, would this be a good alternative? What other standards, layers or alternatives exist for the REST architecture case?

OBS: I am working with PHP but I believe that the language does not become relevant to this case.

Answer 1

Anderson,

Within a Rest-Style architecture, the way you access a data repository to produce your Resources/messages, or to consume them, is not one of the central themes of the service premises published in Rest (Restful Services)

In other words, the way you will do this, whether with DAO or other Design standards, will not directly affect your Rest-style architecture. You may even have memoization methods to respond to requests faster.

The DAO, as a first option

In my experience I worked on several projects with different architectures, the one that offered more flexibility and Separation Of Concerns was DAO with a Dependency Injection - Spring framework for example. I usually inject the implementations of the DAO layer interfaces, the same for the Bos

Premisses Rest

If you’re preoccupied with following the Rest-style architecture guidelines, read them here: http://en.wikipedia.org/wiki/Representational_state_transfer

The language where serivço is actually implemented does not matter, just remember that in Rest HTTP it is not a transport layer, but rather is seen as an API:

• POST
• GET
• DELETE
• PUT

That is, HTTP methods are seen as methods of an API.

Consider JAX-RS

JAX-RS provides an excellent abstraction layer for creating and displaying services in Rest, is considered the State-of-Art within the Java platform

Last, I recommend reading this document:

http://www2008.org/papers/pdf/p805-pautassoA.pdf

Answer 2

I use something similar, but I do it this way:

I avoid dealing with database entities between all layers of the application, so I end up defining a point, where my services and my business rules do not see entities but a Data Transfer Object (DTO). For example:

Productorsource = Layer where services are defined.

Productoservice = Layer where business rules are defined

Produtorepository = Layer of repositories where entities persist in the database.

Between the business rule layer and repositories, I do the DAO to DTO conversion or vice versa.

This is the particular pattern I adopt.

Of course there are 'n' variables still to be considered, such as the Gateway API, so that the client does not get directly to its endpoint, also has the front end and so on.