I have an application that has a web front end handled by spring MVC as well as the same services should be exposed as REST services. So the MVC controllers and rest controllers doing nearly the same thing which results in duplicate code. Now, the question is what is the best practice for the current scenario?
You can refactor your MVC controllers to isolate computation/code services within a #Service or #Component classes and call those from your rest controller as well as MVC controller to get data out so at the same time you will be able to remove redundancy and you will be able to achieve both functionalities.
Related
We have a Spring-boot application that has jsps for view. We are writing REST services to get the data from back-end.
Since the service needs to return a view, it is annotated with #Controller.
How can I implement it such that I can also test these services with Swagger but be able to return the view string from the REST endpoint?
Also examples mention to use #RestController, which I cannot use because of the need to return a view.
Thank you
I come across the URL - https://dzone.com/articles/quick-guide-to-microservices-with-kubernetes-sprin where both the controller and the service methods are exposed as REST API's
The confusion comes and it araises the question whether we need to expose controller methods as REST APIs or Service methods are APIS
if we made both of them as REST APIs then when we call a controller methods - 2 HTTP request might be sent and will cause performance issue.
Please advise.
The example that you're looking at is Feign, it is a declarative webservice client to make webservice calls easier between multiple microservices. Feign comes with GetMapping because its designed to work with other microservices.
In General, Controllers will have RequestMapping and handle the routing and service will do the work of running your business logic.
If we configure 2 RequestMapping it doesn't mean 2 HTTP calls will be made, only the ones with right url will be invoked and the other one will be a simple spring bean.
I am creating an application which has a front end developped using Angular, and a backend developped using SpringBoot.
The problem is that the backend has controllers with request mappings and models (services and repositories) and no views , so does it really implement the MVC pattern?
I have read in this article " Spring MVC or Spring Boot" that spring MVC which itslef implements the MVC pattern is a part of spring boot, so basically spring boot is MVC, which is true when you have views and HTML pages in your project, but in my case i can't talk about views since i am sending and recieving JSON data from a restful API.
According to https://www.wikiwand.com/en/Model%E2%80%93view%E2%80%93controller
view means presentation of the model in a particular format.
I think it is good definition. Particular format in case of backend for REST API happen to be JSON or XML.
From the same page
Some web MVC frameworks take a thin client approach that places almost
the entire model, view and controller logic on the server. In this
approach, the client sends either hyperlink requests or form
submissions to the controller and then receives a complete and updated
web page (or other document) from the view; the model exists entirely
on the server.
In your case the View would be the front-end. The View is the presentation of the data in a human understandable way.
So I believe the View in your case would be the front-end app.
We are writing a mostly single-page, client-side app, but server-side/DB endpoints are still required of course, so the natural choice is SpringMVC (since we are a Java / Spring shop).
But this got me thinking why we need the cluttered, very old design for this app:
- Controller layer
- Service layer
- DAO layer
This app is mostly just the client side making AJAX calls with JSON for DB retrieval/persistence. Do I really need to go thru the Controller layer to receive requests, then invoke a Service method, which in turn invokes a DAO method?
At the same time, I don't want to write a REST Service because it could result in overhead and we may not support all of the REST requirements... but is it the right choice here? If I understand correctly, I would still need a RESTController on the presentation layer?
My goal is to just directly hit a Service method or, maybe even more directly, a DAO method. Is that how modern apps are written?
You cannot hit a DAO unless you expose it through an API of some sort that can be invoked remotely by the UI application; as a consequence, you need to write a service.
A convenient way of exposing a service is to either:
Use Spring MVC and use the controllers as stateless endpoints that provide a JSON/Protobuffer/XML sort of payload that is then parsed by your API (with JSON being the simplest option of them all, perhaps) or
Use Spring Boot, which uses Spring MVC under the hood.
Hope this helps and good luck with your project.
I'm developing a RESTful service using ApacheCXF. I'm using Spring to inject the bean at each layer. I've three layer - REST layer, Service layer (Business logic layer) and DAO layer. I understand that we can annotate Service layer with #Service and DAO layer with #Repository but how do we annotate Rest class ? Do you suggest to annotate it with #Controller ? I've seen many examples where Rest class is annotated as #Controller if you're developing REST using Spring MVC. IMO, Spring MVC comes into play if you have deal with presentation layer as well (I may be wrong, don't have much idea about it) but this is just a web service which is hosted on one server to consume some data by some other application. I've not used Spring MVC in my past, but when would you suggest to develop REST services using Spring MVC? What's the benefit ?
If you're already using Spring, then Spring MVC is the way to write a RESTful service.
Prior to Spring 3, Spring MVC was very much focussed on traditional model-view-controller web apps that typically returned HTML to a web browser. Spring 3 added support for building RESTful services using Spring #Controllers typically configured to return JSON or XML payloads.
Rather than rehashing what's already been written, this blog post is a good introduction to the REST support that was added in Spring 3 and outlines a number of the benefits.