Introduction
In any application you work with regardless it's a monolith or microservices it's common to deal with third parities using HTTP calls, Spring Boot provides multiple ways to do HTTP calls.
RestTemplate Class
RestTemplate is a class responsible for handling HTTP requests and map the response for you, for an example you can do this.
Yeah, this it works fine , but we missed something, regardless static URL in the code, we are communicating with another system over network and this may faces a lot of failures, network may be unstable so the calling fails or another system we deal with has bugs, and all of this might affect badly on our system.
So what, let's add try catch block.
Yes it's more safer now, but what about if we want to handle the exception in special way like log the exception into database or send some notifications to user.
Let's do it,
We did it and works fine, but here is the problem, now we broke Single Responsibility principle and now this method is responsible for many things, so in order to make our code cleaner we may extract all business logic related to calling HTTP request to another service with it's error handling and just use this service to interact with third party.
This better now what about using another technique,
Feign Client
Feign Client also is a component used to handle HTTP requests but in another way, you create an interface then annotate it with @FeignClient and fill annotation properties and type your API signature as method as below.
then you use @Autowired upon interface and now you are having HTTP handler out of the box provided to you from Spring Boot, much easier right, isn't it?
what about error handling?
There are multiple ways to do that you can use fallback property in @FeignClient you can use it to provide fallback class that contains error handling logic, you will find links below about Feign Client.
Feign Client It's not only about ease code writing?
Providing Feign Client in Spring Boot toolbox not only for ease code writing purpose for developer instead of using RestTemplate, but also it has an architectural decision and design.
Let's say you are using RestTemplate for communication with third parties, and Spring team decides that they need to change some RestTemplate method signatures to add some value to the class, off course they have to support backward compatibility and deprecate methods gradually, but in case you need to catch up the updates you have to make changes to your code and test it again and deploy it.
That's the key and main reason behind Feign Client.
While you are using Feign Client you don't depend on concreate class/implementation. Instead, you are using interface and out of the box Spring Boot knows that you are need here HTTP call, so it did that for you without interfering you about how it dose do that, they may still depends on RestTemplate class but they hide that from you, and now they can do whatever change they want and not affecting your code.
Depending on contracts/interfaces while dealing with other system modules or third parties instead of concrete classes, makes your code loosely couple and each module can change its' behavior without affecting other modules.
So you have to follow this rule
Depend on abstractions, not on concretions It means, coding to interfaces, not to concrete classes.
Especially with parts that you expect changes during development process.
At the end, what we were talked about is Dependency Inversion Principle
Resources
IF YOU LIKED THE POST, THEN YOU CAN SUPPPORT SUCH CONTENT WITH A CUP OF COFFEE, THANKS IN ADVANCE.
Top comments (0)