Assuming an application with a traditional UI based on Spring MVC and Thymeleaf, it seems like there are a few ways to expose a REST API...
Add a completely separate set of Controllers using #RestController - Feels like a lot of duplication, but allows complete separation of UI vs REST logic
Use a single Controller for each entity, with a mix of both #ResponseBody methods and ModelAndView methods - Keeps all logic for a given entity in a single place, but requires mixing different concepts
Use a single Controller for each entity, use only ModelAndView, and use content negotiation with a JSON view resolver like the MappingJackson2JsonView (https://spring.io/blog/2013/06/03/content-negotiation-using-views/)
I'm particularly interested in #3 as it feels similar to how Ruby on Rails Controllers work with the respond_to for different content types.
Is this a common approach / best-practice in Spring applications?
Would POST and DELETE requests still require separate methods since they may work differently between a REST API vs the UI? (i.e. posting a form vs posting a json entity)
Would it require separate Exception handling based on whether it was a UI request or API request?
I'd go with option 1. Having a separate set of #Controller and #RestController avoids mixing MVC pattern with your REST api. To avoid code duplication, you should add a service layer and have the REST endpoint and the MVC controller to make use of that service layer.
Related
I do REST API on Spring. Took a course in Spring Data Hibernate and found that it made the REST API the most time-consuming way.
When I added a new entity to the domain, I went through the following chain of objects:
Entity - domain object
DTO - for transmitting/receiving an object to/from a client
Mapper - to convert between Entity and DTO
Repository - for interacting with the database
RestController - for processing API requests
Service - service class for the object
The approximate chain of my actions was as follows:
RestController processes requests - receives DTO from the client (in case of creation of a new object)
Mapper in controller converts DTO to Entity
Service is called
Service accesses the Repository
Repository returns the result of execution (created by Entity)
Service returns Entity is created in RestController
RestController returns to the client an object of type ResponseEntity, where I put the body and response code.
As you can see a large chain of actions and a large number of objects.
But then I found out that if you use Spring Data REST, all this doesn't need all the API supplied by Spring from the box. In general, you only need to create an Entity and Repository.
It turns out that for typical CRUD-type operations, I wrote a lot of controllers and their methods in vain.
Questions:
When should I use RestConroller, and when is Spring Data REST?
Is it possible to combine two approaches for one Entity? It turns out that I was wasting my time writing for simple operations like creating, getting, saving, deleting controllers, it can be moved to Spring Data REST.
Will I be able to implement some of the actions that I did in Spring Data Rest in RestConroller? Such as:
Return an entity property value as id instead of object? I mean I have properties for entities that are entities themselves, for these fields I sometimes need to return their ID instead of the whole entity.
Is there any way to control error handling? In RestController I have implemented the ResponseEntityExceptionHandler extension class and all errors wherever they occur in my RestController are handled in the same way in one place and I always know that all errors will return approximately the same response structure.
Data validation will have to be hinged on the fact that it used to be validated on DTOs received from the client. Are there any nuances waiting for me in this regard?
I'm a little stumped on how to move forward. Give me your recommendations and thoughts on this. Push forward on what to use and how.
What Spring Data REST can do for you is scaffolding of the plain repository to rest service. It is much faster, and in theory it should be flexible, but in practice it is hard to achieve something more than REST access to your repositories.
In production I've used Spring Data REST as a wrapper of the database - in a service/microservice architecture model you just wrap-up sometimes the core DB into such layer in order to achieve DB-agnostic Application. Then the services will apply the business logic on top of this wrapper and will provide API for the front-end.
On the other hand Spring Data Rest(SDR) is not suitable if you plan to use only these generated endpoints, because you need to customize the logic for fetching data and data manipulation into Repoitories/Services. You can combine both and use SDR for the "simple" entities, where you need only the basic CRUD over them, and for the complex entities to go with the standard approach, where you decouple the entity from the endopint and apply your custom business logic into the services. The downside of mixing up both strategies is that your app will be not consistent, and some "things" will happen out-of-the-box, which is very confusing for a new developer on this project.
It loooks wasted time and efforts to write these classes yourself, but it only because your app doesn' have a complex database and/or business logic yet.
In short - the "standard" way provides much bigger flexibility at the price of writing repetetive code in the beginning.
You have much more control building the full stack on your own, you are using DTO's instead of returning the entity objects, you can combine repositories in your services and you can put your business logic on the service layer. If you are not doing anything of the above (and you don't expect to in the near future) there is no need for writing all that boilerplate yet over again, and that's when Spring Data REST comes into play.
This is an interesting question.
Spring Data Rest provides abstraction and takes a most of the implementation in its hand. This is helpful for small applications where the business logic resides at the repository layer. I would choose this for applications with simple straight forward business logic.
However if I need fine grained control (eg: transaction, AOP, unit testing, complex business decisions etc. ) at each of the layers as you mentioned which is most often needed for large scale applications I will prefer writing each of these layers.
There is no thumb rule.
Lately i've been developing a Spring boot application with Angular 5 frontend and i got a little confused about the architecture of it. I was taught to write repositories, services and controllers in spring and to follow the MVC pattern. I started to write the documentation for the app and im trying to describe the arhitecture. So as i think View is the Angular app, C consists of the controller classes, and i described the third layer as buisniss logic which consists of the entity and service classes. But what is the Model really? Did i manage to follow the MVC pattern? In addition i have a controlleradvice, exception classes and security classes that make the authentication and authorization using jwts, but i guess these classes totally stay out from the MVC.
I've searched for the explanation but didnt seem to find it. Could someone please explain this to me? Thank you!
UPDATE
So basically what i dont understand is how the spring classes + angular meet the requirements of the MVC pattern
For example this is one of the first diagrams on the internet when you search for spring layers but as i see these are different from MVC
enter image description here
As mentioned in the comments, both your backend with Spring boot and your frontend with Angular can be seen as different applications, each following the Model-View-Controller design pattern.
You also posted a screenshot of the three-tier architecture. This type of architecture only tells you about how to structure your code. Typically, the MVC-part of your application is within the presentation layer (in your screenshot it's called the web layer).
So, if you would look at your backend application, you can identify the following parts:
Data tier/Repository layer: Repositories
Business tier/Service layer: Services
Presentation tier/Web layer: Model-View-Controller + Dispatcher
Model: Whatever you expose within your services (could be DTOs)
View: JSON structure/mapping
Controller: Spring controllers
And for your frontend you could identify them as well:
Data tier: HTTP calls
Business tier: Angular services
Presentation tier: Components + Router
Model: Whatever you expose within your services (probably a similar structure as the one you expose in your backend)
View: Templates
Controller: Components
This is a bit oversimplified though, and probably not something everyone will agree with.
I am working on the same project with angular as a frontend and spring boot as a backend, and i am still a little bit confused about it's architecture just like you, but i finally had to adopt the MVC model since i am actually using controllers, defining models and rendering views (the json results).
Obviously your front end uses a CBA (component based architecture and your backend is using an MVC pattern since spring MVC is embedded inside spring boot so it actually uses the same logic.
here's a brief image of how spring boot dispatches between controllers and handles requests, you can consider your dispatcher servlet as the middleware between your front end and your backend (but keep in mind that it is embedded inside the spring boot container)
Angular is an SPA, a single-page-application. It contains everything, Model (changing of business data), View (templates with HTML) and Controller (your click- and other event-handlers in your components).
The Spring backend is an extension of the Model, for performing further data transformation and storing it on a database.
The Model-View-Something (there is also MVVM and derivations) is a pattern that comes from desktop-applications, but it doesn't really fit in the world of SPAs. And the Controller in MVC is often seen as redundant even in desktop-applications (because it just delegates stuff and not taking as big role as View and Model).
Important for you to know when you work with Angular is rather the Component-pattern. It is valid in Angular, in React, Vue and even in Vaadin. A component is chunk of both HTML and script-code manipulating that HTML. And components can nest each other allowing a hierarchical architecture.
I need to create a project able to render views (with JSP) and I need to provide a REST API too.
It's possible to have all of this in the same project?
How will the URLs works to access each things?
Thanks you!
If you are trying to follow the strict Roy Fielding-like principles of REST, then probably not.
But if you just want a REST API in a loose meaning, lets say an interface that returns a resource (JSON, HTML, a documents, etc.), sure. Think of it this way. Most web applications (ones that render views) are also going to have some form of AJAX calls, AJAX calls are just calling a REST API (~ish) that returns some JSON (or something) and then JavaScript is going to parse the response and render something on the views.
So, most modern websites that are powered by or assisted by AJAX are going to be a mix of a REST API and a view rendering one.
Hehe. I just made REST developers around the world cringe.
Now, is this a good practice? That is a whole other story. If you are talking about about a large application that is a GUI based and a large application that uses a REST API, normally you don't mix them. Things get confusing and modularity is awesome for maintenance. Also for what it is worth, normally if you are going 100% RESTful, technology you may need for UI development are no longer available since you begin to track state and such. But if its something small or UI related go for it!
As for the URLs, think about this. You tagged Spring so, I am using that.
//I will render a view!
#RequestMapping("/blah")
public String blah(Model model){
return "/view/blah";
}
//I return a JSON string of "/view/blah"
#RequestMapping("/blah")
public #ResponseBody String blah(Model model){
return "/view/blah";
}
Both of these would be inside a #Controller, they are both doing the same thing but the #ResponseBody in a very, very loose sense, makes the second a REST service, as it tells Spring that what you are returning is the response and not to render a view from it. Granted Spring will only try to render a view if you have a ViewResolver set up.
Baeldung has a great breakdown of RESTful controllers versus non in Spring, and yes they can be used in the same application.
Hopefully that helps!
Yes you can mix in an application a classic #Controller with a configuration that provides a view based on JSP and a #RestController that, as you can read from official javadoc, is a
A convenience annotation that is itself annotated with #Controller and
#ResponseBody.
Yes, you can, only have precaution about the url that you configure in your controllers, with #RequestMapping configure the correct URL for every path in your application.
I've read the post MVC With Lazy Loading and i still have some questions:
If we use the 4th choice, which part should be in charge of the transform process? The controller or the service? If we use controller, is it good to introduce #Transactional to controller?
I also see a post that suggested to use different query for different usage. It seems like to use different fetch groups JDO fetchgroup for different purpose. Is it good to use this way?
Thanks.
In today's day and age you can and should expose services as REST controllers and return proper domain objects rather than ModelAndView or other such constructs from Spring MVC.
UPDATE: Clarification: There is NO controller class in this approach I am suggesting. Expose Service as #Controller. Expose public methods on service as REST and annotate transnational, authorization etc context on the method. Because from an API point of view this public interface serves all kinds of clients whether it is REST or direct method call.
Also if you have dedicated controllers and services you may see some business logic seeping into your controllers in no time.
I would go to even further and not use option 4 which is essentially leads to a DTO anti-pattern.
Having said that it still depends on the complexity of entities. A very complex entity with many association is going to be a performance hog due to the queries it fires. Yet your MVC (JSPs) may actually resolve the associations whenever needed. (In a side note with full REST full architecture this is an issue.)
If I need to build a web application that implement functionalities related to managing an Medical hospital institution. That application include functionalities to add, update, delete, search and retrieve patients, medical visits, etc.
So I am confused on which approach to follow inside my ASP.NET MVC web application, either to have my controller classes inside my asp.net MVC.
Derived from IController to perform the CRUD operation
OR
Derived from ApiController to perform the CRUD operations
SECOND question is there an approach that is taking over the other, and what are the advantages/disadvantages of each approach over the other?
You can absolutely use both. Nothing stops you to use good old Controller to do CRUD in JSON and MVC is capable of doing it. However, you do not get all the nice features of Web API such as content negotiation, message handlers, media type formatters, etc.
If you do not need any of Web API specific features, then use MVC. But on the long run, Web API will be a better investment as I believe adoption will rocket soon.
If you are going to generate classical HTML pages from your controllers, use the MVC ones. If what you want to return to a client is some kind of serialized data (XML, JSON, ...), use Web API controllers since these make it easier, regarding e.g. content negotiation.
See also Getting started with Web API