I looked for the similar question but could not find any . I have a micro service created with drop-wizard which is running in localhost:9000.
I am working in another project(with spring mvc) running in 8080. I wan to call the above service which gives me string back from any of my controllers in main project .lets say the path is "localhost:9000/giveMeString" .
You can use Apache's HTTP Client. See this example borrowed from their documentation:
// Create an instance of HttpClient.
HttpClient client = new HttpClient();
// Create a method instance.
GetMethod method = new GetMethod("http://localhost:9000/giveMeString");
// Execute the method.
int statusCode = client.executeMethod(method);
// Read the response body.
byte[] responseBody = method.getResponseBody();
//Print the response
System.out.println(new String(responseBody));
If you're really going down the microservice path, note that creating an HTTP client for every request and making synchronous, blocking requests won't really scale.
Here are a few ideas, if you're using Spring:
Create a single RestTemplate instance
You can create a single RestTemplate instance and inject it in multiple places in your application.
#Configuration
public class MyConfiguration {
#Bean
public RestTemplate restTemplate() {
return new RestTemplate(new HttpComponentsClientHttpRequestFactory());
}
}
Better, wrap that REST client with a Cache
Check out Sagan's take on this.
Even better, go asynchronous
You can use an AsyncRestTemplate; very useful, especially if your Controllers need to make multiple requests and if you don't want to block your webapp thread. Your Controller can even return a DeferredResult or a ListenableFuture, which will make your webapp more scalable.
And Spring Cloud + Netflix
You can also check Spring Cloud and Spring Cloud Netflix.
You'll see there interesting features: load-balancing, recovery, circuit breakers, etc.
Related
I am using Resttemplate to build an simple API gateway in spring-boot project. When my gateway receive a request from client, it dispatch the request to another Service through RESTful call, and then pass the response back to client.
My code snippet like below:
#RestController
#RequestMapping("api/v1/message")
public class GatewayController {
#PostMapping
public ResponseEntity<Response> dispatchRequest(#RequestBody Request request) {
validateInput(request);
Response response = restTemplate.post(URL_OF_ANOTHOER_SERVICE, request, ...);
return ResponseEntity.ok(response);
}
}
I have more than 100 requests per second approximately, and I know that Resttemplate is thread-safe.
My questions:
Is Resttemplate OK to do such work? Will it become bottleneck?
Is there any other suggestions?
Thank you very much.
You can try Spring Cloud Gateway or Spring Cloud Netflix.
You don`t need to build a gateway from scratch unless you want. And even if you want to, you could consider aspects such as security, maturity and maintenance
Some modules of Spring Cloud Netflix
have gone into maintenance mode, therefore, Spring Cloud Gateway might be a good option as GJohannes quoted
I am using Spring RestTemplate for executing HTTP request from my application. There are several services we need to call, some on the internet and some on intranet, some fast and some slow. I have been instructed to configure custom settings for each service, basically, connection timeout, read timeout.
These setting will be extremely specific for example, the services hosted on intranet would have a timeout of ~2-5s while they provide an SLA of 1000ms for 99.9% of requests. While the other third party services with ~10-60s.
As these parameters can be set in the factory for the template only, i am creating a number of beans with different factories differing in timeouts only. Something like this:
#Bean
RestTemplate restTemplate() {
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient);
factory.setReadTimeout(20000);
factory.setConnectTimeout(5000);
RestTemplate restTemplate = new RestTemplate(factory);
}
I am afraid this will create a maintenance nightmare eventually. Can it be solved in a better ways?
PS: The application is a monolith calling various services.
You will have to create multiple RestTemplates and assign timeouts, connection pool size. Connection pool will improve the performance drastically
I have hard-coded the connection properties, you can pick it from application.properties file
#Configuration
class RestTemplateConfigs {
#Bean
public HttpClient httpClient() {
return HttpClientBuilder.create()
.setMaxConnPerRoute(200)
.setMaxConnTotal(50)
.setConnectionTimeToLive(10L, TimeUnit.SECONDS)
.build();
}
#Bean(name = "restTemplate1")
RestTemplate restTemplate() {
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient());
RestTemplate restTemplate = new RestTemplate(factory);
return restTemplate;
}
}
You can create multiple RestTemplates and Autowire it using Qualifier name.
Disclaimer: my answer suggests to work with another Http client than Rest Template - If you must use Rest template my answer would be irrelevant.
I dealt with a similar design issue and here is what I did. I wrote my own HttpClient class. It is much simpler in use then most known Http clients. This class could be used on its own or (and this is relevant for your case) it could be used as a parent class for a group of classes (implementing the same interface) where each class will be an Http client for specific Rest Service. On this class you can pre-set the target URL and all the parameters (such as read and connection timeouts etc). Once this class is preset, all you need to do is to invoke sendHttpRequestMethod(). Just to expand a bit - lets say you have a User Rest service with CRUD API implemented by particular URL calls with different HTTP methods and may be different URLs. (say in addition to create (POST) update (PUT) read (GET) and delete (DELETE) methods that are located at HTTP://www.myserver.com:8083/user say you will also have methods activate and deactivate (say both GET) at URLs HTTP://www.myserver.com:8083/user/activate/ and HTTP://www.myserver.com:8083/user/deactivate.
So, in this case, your Http client will set all required timeouts and other configurations and it will also have pre-set target URL HTTP://www.myserver.com:8083/user. and it will have six methods as mentioned above, where each one will simply invoke the parent class method sendHttpRequest(). Of course, for activate and deactivate methods you will need to append "activate" and "deactivate" suffixes for pre-set base URL. So, for each REST service, you can create a dedicated Http client with very minimal effort since the base class already does most of the job. In addition to it, I wrote a self-populating factory for any group of classes that implement the same interface. With that factory, all you will have to do is to write your additional Http client and the factory will detect it and will make it available on its own by predefined name or by the name of the class (based on your choice). All this worked so well for me, that I packaged it into Open Source library called MgntUtils and published it on Maven and Github (with source code and Javadoc. JavaDoc is available here). A detailed explanation on the Self-populating factory can be seen in Javadoc here. Also, the general article about the library can be found here and specific article about the idea and the implementation of self-populating Factory can be found here. Package com.mgnt.lifecycle.management.example in the source code contains a working example. I hope this helps.
Using parameterized construction of the RestTemplate bean solved my problem.
The bean is now configured as:
#Bean
#Scope(BeanDefinition.SCOPE_PROTOTYPE)
public RestTemplate getRestTemplate(String configParam){
int connectionTimeout; //get from config using configParam
int readTimeout; //get from config using configParam
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(connectionTimeout);
factory.setReadTimeout(readTimeout);
return new RestTemplate(factory);
}
Instead of #Autowiring this field, it can be injected in may be #PostConstruct method like depicted below. The dependent bean can do following:
#Autowire
BeanFactory beanFactory;
RestTemplate restTemplate;
#PostConstruct
public void init(){
restTemplate = beanFactory.getBean(RestTemplate.class, configParam);
}
Here you can have your bean with custom settings injected in restTemplate.
I am confused about how an infinite loop of feign calls might behave.
An example:
Assume I have 2 APIs, A & B.
if I call API A, which in turn calls API B via a feign HTTP call, which in turn calls API A again via feign, will it recognize this and break the call chain?
Quick flowchart of calls:
A -> B -> A -> B ... Repeat infinitely?
I have not tried this code, it is just an idea。
But I am assuming that spring-cloud-starter-feign will provide some methods to resolve this problem? Is this assumption correct?
#PostMapping(RestJsonPath.API_A)
ResponseEntity<byte[]> apiA();
#PostMapping(RestJsonPath.API_B)
ResponseEntity<byte[]> apiB();
Will it execute until it times out or hystrix will stop it？
TL;DR:
Feign will keep the connection open on the initial request from A to B until the pre-configured timeout kicks in. At this point, Feign will time out the request and if you have specified a Hystrix fallback, Spring will use your Hystrix fallback as the response.
Explanation:
spring-boot-starter-feign provides an abstraction layer for writing the HTTP request code. It will not handle potential loops or cycles in your code.
Here is an example spring boot feign client from their tutorials website for demonstration:
#FeignClient(value = "jplaceholder",
url = "https://jsonplaceholder.typicode.com/",
configuration = ClientConfiguration.class,
fallback = JSONPlaceHolderFallback.class)
public interface JSONPlaceHolderClient {
#RequestMapping(method = RequestMethod.GET, value = "/posts")
List<Post> getPosts();
#RequestMapping(method = RequestMethod.GET, value = "/posts/{postId}", produces = "application/json")
Post getPostById(#PathVariable("postId") Long postId);
}
Notice first that this is an interface - all the code is auto generated by Spring at startup time, and that code will make RESTful requests to the urls configured via the annotations. For instance, the 2nd request allows us to pass in a path variable, which Spring will ensure makes it on the URL path of the outbound request.
The important thing to stress here is that this interface is only responsible for the HTTP calls, not any potential loops. Logic using this interface (which I can inject to any other Spring Bean as I would any other Spring Bean), is up to you the developer.
Github repo where this example came from.
Spring Boot Docs on spring-boot-starter-openfeign.
Hope this helps you understand the purpose of the openfeign project, and helps you understand that it's up to you to deal with cycles and infinite loops in your application code.
As for Hystrix, that framework comes in to play (if it is enabled) only if one of these generated HTTP requests fails, whether it's a timeout, 4xx error, 5xx error, or a response deserialization error. You configure Hystrix, as a sensible default or fallback for when the HTTP request fails.
This is a decent tutorial on Hystrix.
Some points to call out is that a Hystrix fallback must implement your Feign client interface, and you must specify this class as your Hysterix fallback in the #FeignClient annotation. Spring and Hystrix will call your Hystrix class automatically if a Feign request fails.
I have a scenario where there is an aggregate endpoint to call multiple downstream systems which are RESTful and gives back the consolidated response from all these systems.
I am currently using a rest template that is configured as a singleton bean and injects it to the corresponding services to make the rest call. The RestTemplate is using the default CloseableHttpClient as the HttpClient, which will close the connections once the request is successful.
Would this be a good approach or would it be better if the rest template is configured per service that is calling its RESTful service?
RestTemplate is thread safe. You could use a pooling connection manager:
#Bean
public PoolingHttpClientConnectionManager poolingHttpClientConnectionManager() {
PoolingHttpClientConnectionManager result = new PoolingHttpClientConnectionManager();
result.setMaxTotal(20); // FIXME Consider making this value configurable
return result;
}
#Bean
public RequestConfig requestConfig() {
RequestConfig result = RequestConfig.custom()
// FIXME Consider making these values configurable
.setConnectionRequestTimeout(2000)
.setConnectTimeout(2000)
.setSocketTimeout(2000)
.build();
return result;
}
#Bean
public CloseableHttpClient httpClient(PoolingHttpClientConnectionManager poolingHttpClientConnectionManager, RequestConfig requestConfig) {
CloseableHttpClient result = HttpClientBuilder
.create()
.setConnectionManager(poolingHttpClientConnectionManager)
.setDefaultRequestConfig(requestConfig)
.build();
return result;
}
#Bean
public RestTemplate restTemplate(HttpClient httpClient) {
HttpComponentsClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory();
requestFactory.setHttpClient(httpClient);
return new RestTemplate(requestFactory);
}
And also important, you might need to change RestTemplate's default settings based on observation / load tests, RestTemplate doesn't necessary use the whole pool to prevent a host from hijacking it.
You can read more at my blog Troubleshooting Spring's RestTemplate Requests Timeout
From Spring Docs
RestTemplate
The RestTemplate is the central Spring class for client-side HTTP
access. Conceptually, it is very similar to the JdbcTemplate,
JmsTemplate, and the various other templates found in the Spring
Framework and other portfolio projects. This means, for instance, that
the RestTemplate is thread-safe once constructed, and that you can use
callbacks to customize its operations.
Hence you can create your RestTemplate its safe to share with multiple threads invoking a REST call simultaneously.
You should also consider cost of creating and destroying an instance. If each thread or each rest call creates a dedicated RestTemplate it will hamper your apps performance.
Ref: https://spring.io/blog/2009/03/27/rest-in-spring-3-resttemplate
It would be better if you're injecting the services in the rest template if they have something in common. You can inject services with some common behavior in one rest template. This way you'll be able to implement some resuable code in say a parent class. Just because they all are a service, injection them in a single rest template might not be proper from design point of view.
I am trying to unit test a Spring bean I implemented, but come across a difficulty here. This bean is to call a distant REST service on certain occasions.
However, in my tests, I would like it to call a mock servlet inside my test context, not a distant server.
The call is made using Apache's httpclient library, the URL is set in the applicationContext (so I can provide any fake URI to the bean when testing). The service should return a stream.
The call looks like the following:
HttpClient client = new DefaultHttpClient();
URIBuilder builder = new URIBuilder(theURIProvidedInContext);
// set parameters on builder
URI uri = builder.build();
HttpGet get = new HttpGet(uri);
HttpEntity entity = client.execute(get).getEntity();
return entity.getContent();
I searched Google all morning but only found how to unit-test servlets. Can anybody give some insight here?
You're not going to be able to call a mock servlet in a test context because there's no application server. Instead, you can pull out that code that uses HTTP Client to make the call into a separate bean, and then mock that to return the desired stream.
If it's a REST service, you can create a JAX-RS annotated class as a test double (I won't call it a mock), and start it with an embedded server like Grizzly or Jersey. That will start up an HTTP server for you. Your annotated class can throw 404, 500, etc. depending on how you want the test to proceed. See JAX-RS with embedded server
Try com.rexsl.test.ContainerMocker from com.rexsl:rexsl-test:mock:0.3.8 (I'm a developer):
URI home = new ContainerMocker()
.expectMethod("GET")
.expectHeader("Accept", Matchers.startsWith("text/"))
.returnBody("<done/>")
.returnStatus(200)
.mock()
.home();
Now you have a URI with a running HTTP container, which you can inject it into your classes.