I have a spring application. It exposes an endpoint, which when hit, needs to make an call to some other API. So, where should I make this API call, inside my controller itself or should I do it in the service class?
Based on any Architectural style (DDD, Microservices, etc), we should follow separation of concerns.
Best practice would be to create a Rest Client class for the API you want to consume and make all rest calls inside that.
Then you create a Service class to call the method consuming the API, performing the operation, data filter, anything you want to do with data.
Next would be to inject your service class inside the controller and return the data you just consumed and did some operation on it.
It might not sound well in a small project/feature, but it is the best practice when things get complicated and grow.
Related
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 have an application which looks like this
Now, whenever a request is received at the gateway, Zuul filter AuthorizationInterceptor gets invoked which does authentication/authorization by making some calls with User Service. If the authorization succeeds then actual microservice is called.
Now the with the new requirement, I need to write some aggregated API which takes data from two services and combine the data. So I added #RestController on Gateway Proxy but before that rest controller gets invoked AuthorizationInterceptor is not getting invoked. How can I tell ZuulFilter to get invoked even when the request is locally served.
Is there any solution for this? Should this be architected in a different way?
I don't think it's a good idea to put this kind of logic into the gateway service.
What you are referring to is an aggregator service which can be after the gateway as the other two services but instead of storing data or doing some business logic, it just takes the data from the two other services and aggregates them. This way the AuthorizationInterceptor will be invoked on the gateway level as well.
Another hacky approach would be to create a custom ZuulFilter which handles an imaginary endpoint call and aggregates the data. This way your AuthorizationInterceptor will be called as well but it's not a good idea to put this kind of logic into your edge service.
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.
SETUP
At present I have a controller heavy spring MVC application. Its components are heavily guarded with spring security. Most of the datamodel fetching, form binding etc... is done within controllers.
I however see great value addition in using spring web flow.
However I would like to use web flow in a specific way.
First of all I would like the web flow to be like traffic police directing web requests to appropriate controllers inside every state (Along with form binding objects, request, session params etc...).
I would like the controller to ultimately determine direction of web flow like successful login or goto registration page. However it is web flow that will consume the decision and facilitate the transition to the next state.
This next state will in turn leverage mvc by invoking appropriate controllers.
This way spring web flow is just like a facilitator and does not contain too much decision making logic & business logic invocation calls.
This is important for me since controllers can get heavy with respect to services it invokes and can potentially invoke them in a multi-threaded approach. All this cannot be done in spring web flow definitions
QUESTION
My question is very simple and basic. Is Spring Web Flow designed to perform like this on top of Spring MVC?
Is it possible to designate just this traffic regulation and state flow functionality to web flow while preserving most of the control and service invocation logic inside the controller?
--Am I understanding anything wrong here? I want to get these questions cleared before
embarking along this path.
This may be a little late for you, but I'm not sure webflow will give you exactly what you want to achieve. You want a router, and that's not really what webflow was designed for. Webflow is used more for multi-page form type flows, and using it for much more risks running into the limitations of the framework. Webflow cannot be used to intercept all web requests -- only those initiated through the flow mechanism, and it has very strong opinions on what state transition is (for example, form/bean validation is the default, although it can be overridden if required).
It's not that it can't be used as a router, it's just that it's not designed for this so you're likely to find impedance from its form based design goals.
I have a controller to send send a message from my site:
example.com/contact/send-message
Ok here, but in my API I've created the same method:
api.example.com/contact/send-message
in the API should I keep the same method and just call the method inside the controller? When should I use controller methods or api methods?
By all means, separate your API logic from your web application logic. One will be used via a web browser, and the other one will just interface with other software. Each of them solves different problems.
Use a fat model, thin-controller approach. Meaning that all the data processing methods should be placed in your model, not in the controller. From there, you can call those methods either from your API controller, or from your web controller.
An excellent plugin to build a restful API is Phil Sturgeon's REST Server