Layers to develop web service

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 services assumptions published in Rest (Restful Services)

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

DAO as first choice

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

Rest Assumptions

If you are worried about following the guidelines of the Rest-style architecture, read about them here: link

p>

The language in which the web service is actually implemented does not matter, just remember that in HTTP rest 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 exposing services in Rest, it is considered the State-of-Art within the Java platform

Finally, I recommend reading this document:

link

    

I use something similar, but I do it as follows:

I avoid getting traffic with the 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:

  

ProductResource = Layer where services are defined.

     

ProductService = Layer where business rules are defined

     

ProductRepository = Repository layer where entities persist in the database.

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

This is the particular pattern I adopt.

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