Most applications today make HTTP requests to external services. When using Spring Cloud, one way to make these requests is to use what we call a “load balanced RestTemplate”. Creating a load balanced RestTemplate is pretty straightforward.

The added @LoadBalanced annotation allows you to take advantage of services registered with a discovery service, such as Eureka. As you can see in the doOtherStuff method, we are making a request to the URL http://stores/stores. The hostname, stores, is not actually a registered hostname. Instead, it is the name of the stores service registered with the discovery server. The RestTemplate, in this case, will replace the stores hostname with the hostname (or IP address) of the stores service.

As we are all aware, making requests like this can be problematic. For any number of reasons, something may go wrong and the request could fail. That is why, in robust applications, API requests like the one above may be retried when failures are encountered. It might be the case that the service is completely down and we are never going to get a response. However, it is equally as likely that the failure was due to some kind of fluke network issue and a subsequent request may succeed. It could even be the case that a given instance of a service may be experiencing problems, but there is another instance available that might be perfectly capable of handling our request.

In Spring Cloud, if you used a load balanced RestTemplate to make your API request and the request failed, then it was up to you, the developer, to retry the request. As of Camden.SR2, we have introduced some retry handling into load balanced RestTemplates. We now take advantage of the awesome Spring Retry project to provide the retry logic. You can use Ribbon properties to configure how many retry requests are made, and which requests are retried.

In the future, we will be using Spring Retry when making API requests with Feign as well as when requests are made through Zuul.