Sep 24, 2020 Apache HttpClient is a low-level, lightweight client-side HTTP library for communicating with HTTP servers. In this tutorial, we'll learn how to configure the supported Transport Layer Security (TLS) version(s) when using HttpClient. We'll begin with an overview of how TLS version negotiation works between a client and a server. Discover Spring 5's WebClient - a new reactive RestTemplate alternative. It's important to note that even though it is, in fact, a non-blocking client and it belongs to the spring-webflux library, the solution offers support for both synchronous and asynchronous operations, making it suitable also for applications running on a Servlet Stack. Apache HttpClient i About the Tutorial Http client is a transfer library. It resides on the client side, sends and receives Http messages. It provides up to date, feature-rich, and an efficient implementation which meets the recent Http standards. Audience This tutorial has been prepared for the beginners to help them understand the concepts.
- Apache HttpClient Tutorial
- Apache HttpClient Resources
- Selected Reading
Using HttpClient, we can perform Multipart upload, i.e., we can upload larger objects insmaller parts. In this chapter, we demonstrate the multipart upload in HTTP client by uploading a simple text file.
In general, any multipart upload contains three parts.
Initiation of the upload
Uploading the object parts
Completing the Multipart upload
For the multipart upload using HttpClient, we need to follow the below steps −
Create a multipart builder.
Add desired parts to it.
Complete the build and obtain a multipart HttpEntity.
Build request by setting the above muti-part entity.
Execute the request.
Following are the steps to upload a multipart entity using the HttpClient library.
Step 1 - Create an HttpClient object
The createDefault() method of the HttpClients class returns an object of the class CloseableHttpClient, which is the base implementation of the HttpClient interface. Using this method, create an HttpClient object −
Step 2 - Create a FileBody object
FileBody class represents the binary body part backed by a file. Instantiate this class by passing a File object and a ContentType object representing the type of the content.
Step 3 - Create a MultipartEntityBuilder
The MultipartEntityBuilder class is used to build the multi-part HttpEntity object. Create its object using the create() method (of the same class).
Step 4 - Set the mode
A MultipartEntityBuilder has three modes: STRICT, RFC6532, and BROWSER_COMPATIBLE. Set it to the desired mode using the setMode() method.
Step 5 - Add various the desired parts
Using the methods addTextBody(), addPart() and, addBinaryBody(), you can add simple text, files, streams, and other objects to a MultipartBuilder. Add the desired contents using these methods.
Step 6 - Building single entity
You can build all these parts to a single entity using the build() method of the MultipartEntityBuilder class. Using this method, build all the parts into a single HttpEntity.
Step 7 - Create a RequestBuilder object
The class RequestBuilder is used to build request by adding parameters to it. If the request is of type PUT or POST, it adds the parameters to the request as URL encoded entity.
Create a RequestBuilder object (of type POST) using the post() method. And pass the Urito which you wanted to send the request it as a parameter.
Step 8 - Set the entity object to the RequestBuilder
Set the above created multipart entity to the RequestBuilder using the setEntity() method of the RequestBuilder class.
Step 9 - Build the HttpUriRequest
Build a HttpUriRequest request object using the build() method of the RequestBuilder class.
Step 10 - Execute the request
Using the execute() method, execute the request built in the previous step (bypassing the request as a parameter to this method).
Example
Following example demonstrates how to send a multipart request using the HttpClient library. In this example, we are trying to send a multipart request backed by a file.
Output
On executing, the above program generates the following output −
JAX-RS : Client API
- JAX-RS 2.0 Client API
- Proxy-based API
- CXF WebClient API
In CXF 2.7.x no JAX-RS 2.0 Client API is supported and CXF specific Client API is located in the cxf-rt-frontend-jaxrs module.
CXF Apache HttpClient based transport is required to get the asynchronous invocations working correctly:
CXF 3.0.0 implements JAX-RS 2.0 Client API. Internally it is implemented in terms of CXF specific WebClient.
The javax.ws.rs.client provides a short overview of how JAX-RS 2.0 Client API works.
Typically, one starts from ClientBuilder in order to create a Client.
Next WebTarget is created and further customized as needed.
Next, Invocation.Builder is initialized and the request can be made immediately using one of the SyncInvoker methods, with the builder directly implementing SyncInvoker.
The above sequence can be easily collapsed into a single code sequence if preferred.
Note that SyncInvoker (and AsyncInvoker) expects Entity to represent the request body.
Invocation.Builder has a shortcut to Invocation via its build(...) methods to further customize the invocation.
Invocation.Builder.async() links to AsyncInvoker.
Client and WebTarget are all can be individually configured, the implement Configurable interface which can accept the providers and properties and return Configuration. Configuring the Client directly or indirectly via ClientBuilder.withConfig method affects all the WebClients spawned by a given Client.
JAX-RS 2.0 and CXF specific API
CXF proxy and WebClient client code has been retrofitted to support JAX-RS 2.0 client filters, reader and writer interceptors, new exception classes and Response API.
WebClient offers shortcuts to JAX-RS 2.0 AsyncInvoker and SyncInvoker interfaces.
WebClient.getConfig(Object client) supports JAX-RS 2.0 WebTarget and Invocation.Builder for 2.0 clients to be able to get to the lower-level CXF configuration and set up the properties such as 'receiveTimeout', etc.
With the proxy-based API, one can reuse on the client side the interfaces or even the resource classes which have already been designed for processing the HTTP requests on the server side (note that a cglib-nodeps dependency will need to be available on the classpath for proxies created from concrete classes). When reused on the client side, they simply act as remote proxies.
Apache Httpclient Download
JAXRSClientFactory is a utility class which wraps JAXRSClientFactoryBean. JAXRSClientFactory offers a number of utility methods but JAXRSClientFactoryBean can also be used directly if desired.
For example, given these class definitions:
the following client code retrieves a Book with id '1' and a collection of books:
When proxies are created, initially or when subresource methods are invoked, the current URI is updated with corresponding @Path, @PathParam, @QueryParam or @MatrixParam values, while @HttpHeader and @CookieParam values contribute to the current set of HTTP headers. Same happens before the remote invocation is done.
It is important to understand that strictly speaking there is no direct relationship between a given method on the client side and the same one on the server side. The job of the proxy is to construct a correct URI according to given class and method specifications - it may or may not be the same method on the corresponding server class that will be invoked (provided of course that it is a JAX-RS annotated server resource class - but that may not be the case!) More often than not, you will see a method foo() invoked on a server resource class whenever the same method is invoked on the corresponding remote proxy - but in the presence of @Path annotations with arbitrary regular expressions this is not guaranteed, however this doesn't matter, as the most important thing is that a proxy will produce a correct URI and it will be matched as expected by a server class.
Client-side MessageBodyReaders and MessageBodyWriters are used to process request or response bodies just as they do on the server side. More specifically, method body writers are invoked whenever a remote method parameter is assumed to be a request body (that is, it has no JAX-RS annotations attached) or when a form submission is emulated with the help of either @FormParams or the JAX-RS MultivaluedMap.
Apache Httpclient
You can make multiple remote invocations on the same proxy (initial or subresource), the current URI and headers will be updated properly for each call.
If you would like to proxify concrete classes such as BookStoreImpl for example (say you can not extract interfaces), then drop the cglib-nodeps.jar on a classpath. Such classes must have a default constructor. All methods which have nothing to do with JAX-RS will simply be ignored on the client side and marked as unsupported.
Customizing proxies
Proxies end up implementing not only the interface requested at proxy creation time but also a Client interface. In many cases one does not need to explicitly specify commonly used HTTP headers such as Content-Type or Accept as this information will likely be available from @Consumes or @Produces annotations. At the same time you may explicitly set either of these headers, or indeed some other header. You can use a simple WebClient utility method for converting a proxy to a base client:
You can also check a current set of headers, current and base URIs and a client Response.
Converting proxies to Web Clients and vice versa
Using proxies is just one way to consume a service. Proxies hide away the details of how URIs are being composed while HTTP-centric WebClients provide for an explicit URI creation. Both proxies and http clients rely on the same base information such as headers and the current URI so at any moment of time you can create a WebClient instance out of the existing proxy:
At any moment of time you can convert an http client into a proxy too:
Handling exceptions
There are a couple of ways you can handle remote exceptions with proxies.
One approach is to register a ResponseExceptionMapper as a provider either from Spring using a jaxrs:client or using a corresponding JAXRSClientFactory utility method. This way you can map remote error codes to expected checked exceptions or runtime exceptions if needed.
If no ResponseExceptionMapper is available when a remote invocation failed then an instance of javax.ws.rs.WebApplicationException will be thrown (Note org.apache.cxf.jaxrs.client.ServerWebApplicationException is used to represent the server exceptions before CXF 2.7.0.). At this point of time you can check the actual Response and proceed from there:
javax.ws.rs.ProcessingException will be thrown if the exception has occurred for one of two reasons:
- the remote invocation succeeded but no proper MessageBodyReader has been found on the client side; in this case the Response object representing the result of the invocation will still be available
- the remote invocation has failed for whatever reasons on the client side, example, no MessageBodyWriter is available.
Note org.apache.cxf.jaxrs.client.ClientWebApplicationException is used to represent the client processing exceptions before CXF 2.7.0.
Configuring proxies in Spring
When creating a proxy with JAXRSClientFactory, you can pass a Spring configuration location as one of the arguments. Or you can create a default bus using Spring configuration and all proxies will pick it up:
Injecting proxies
For injecting proxies via a spring context, use the jaxrs:client element like:
See this bean for a full example of how jaxrs:client can be used to inject a proxy. Note that WebClient can also be injected as a jaxrs:client.
Asynchronous proxy invocations
Starting from CXF 3.1.7 it is possible to do the asynchronous proxy invocations. One needs to register JAX-RS 2.0 InvocationCallback as a proxy request context property:
If you have a proxy with different methods returning different response types then either register an Object bound InvocationCallback or register a collection of type-specific callbacks:
Make sure a proxy is created in a thread safe mode if it is being accessed by multiple threads for every new request thread to have its own callback.
Buffering Responses
One way to buffer proxy responses is to have a proxy method return JAX-RS Response, use its bufferEntity() method (available in JAX-RS 2.0) and use Response.readEntity which can return typed responses if preferred.
The other option is to have a 'buffer.proxy.response' property enabled on a given proxy instance.
Limitations
Proxy sub-resource methods returning Objects can not be invoked. Prefer to have sub-resource methods returning typed classes: interfaces, abstract classes or concrete implementations.
Working with user models
Proxies can be created with the external user model being applied to a proxy class, for example:
Apache Http Client Keystore
BookNoAnnotations is either an interface or concrete class with no JAX-RS annotations. Both client proxies and server endpoints can 'turn' it into a RESTful resource by applying an external user model.
HTTP centric clients are WebClient instances which also implement the Client interface. In addition to setting various Client request properties, you can also make an explicit HTTP invocation with an HTTP verb being the name of a given operation :
You can choose to get an explicit JAX-RS Response instead and check the response code, headers or entity body if any:
WebClient lets you get back to a base URI or to a previous path segment and move forward, it can be handy for getting a number of individual entries from a service with ids embedded in path segments :
The above code will send requests like 'GET http://books/1', 'GET http://books/2', etc.
If the request URI can be parameterized then you may want to use the following code:
When reusing the same WebClient instance for multiple invocations, one may want to reset its state with the help of the reset() method, for example, when the Accept header value needs to be changed and the current URI needs to be reset to the baseURI (as an alternative to a back(true) call). The resetQuery() method may be used to reset the query values only. Both options are available for proxies too.
Asynchronous invocations
WebClient has several methods accepting JAX-RS 2.0 InvocationCallback and returning Future. Alternatively, users can also use WebClient.async() shortcut to work with a standard AsyncInvoker.
Working with explicit collections
WebClient supports GenericEntity and JAX-RS 2.0 GenericType directly and via JAX-RS 2.0 SyncInvoker and AsyncInvoker to make it easier to work with the explicit collections.
WebClient also has few collection-aware methods, example:
Handling exceptions
You can handle remote exceptions by either explicitly getting a Response object as shown above and handling error statuses as needed or you can catch either javax.ws.rs.WebApplicationException or javax.ws.rs.ProcessingException exceptions, the same way it can be done with proxies.
Configuring HTTP clients in Spring
Like proxies, HTTP clients can be created using a number of WebClient static utility methods: you can pass a location to a Spring configuration bean if needed or you can set up a default bus as shown above. For example:
Note, starting from CXF 2.7.5 it is possible to set-up WebClient instances the same way as proxies, using jaxrs:client:
The only limitation of using this option is that some of jaxrs:client attributes ('inheritHeaders', 'modelRef') and elements ('model') are not really applicable to WebClient.
XML-centric clients are WebClients using an XMLSource utility class. XMLSource has a number of methods facilitating the retrieval of JAXB beans, individual properties or links with the help of XPath expressions. For example:
Note that an XMLSource instance can be set to buffer the input stream thus allowing for executing multiple XPath queries.
XMlSource can also help with getting the URIs representing the links or XML instances as Strings.
To get the arbitrary HTTP methods supported with the synchronous client calls or bypass some known Java HTTPUrlConnection issues (example it will block empty DELETE requests) add the HttpClient-based transport dependency and set a 'use.async.http.conduit' contextual property.
This will work as is for asynchronous calls given that the HttpClient-based transport is required.
Proxies and web clients (clients) are not thread safe by default. In some cases this can be a limitation, especially when clients are injected; synchronizing on them can cause performance side effects.
One way to 'make' clients thread-safe is to use WebClient.fromClient(Client) for web clients or JAXRSClientFactoryBean.fromClient() factory methods which copy all the original configuration properties and can be used to create new client instances per every request.
A single client doing multiple invocations without changing the current URI or headers is thread-safe (while creating a Invocation.Builder instances concurrently is not thread-safe since the shared instance of non-thread-safe class ClientProviderFactory is used under the hood). The only limitation in this case applies to proxies, in that they can not get 'out of band' headers without synchronizing, ex :
Final option is to use a 'threadSafe' boolean property when creating proxies or web clients (either from Spring or programmatically), see this test for more details. Thread-safe clients created this way keep their state in a thread-local storage.
If a number of incoming threads is limited then one option is just do nothing, while the other option is to reset the thread local state :
Yet another option is to use JAXRSClientFactoryBean and a 'secondsToKeepState' property for creating thread-safe clients - this will instruct clients to clean-up the thread-local state periodically.
Proxy and http-centric clients are typically created by JAXRSClientFactory or WebClient factory methods but JAXRSClientFactoryBean can also be used for pre-configuring clients before they are created.
Sometimes, you may want to configure a client instance after it is been created. For example, one may want to configure HTTPConduit programmatically, as opposed to setting its properties using Spring. ClientConfiguration represents a client-specific configuration state and can be accessed like this :
When working with JAX-RS 2.0 Client API one can set some low-level HTTP properties via Configurable interface:
Example :
There's a number of ways to configure HTTPConduits for proxies and WebClients.
It is possible to have an HTTPConduit configuration which will apply to all clients using different request URIs or only to those with using a specific URI. For example:
This configuration will affect all proxies and WebClients which have requestURIs starting from 'http://books:9095/bookstore'. Note the trailing '.*' suffix in the name of the http:conduit element.
Please see this configuration file for more examples.
Alternatively you can just do:
This configuration will affect all the clients, irrespective of the URIs being dealt with.
If you work with proxies then you can have the proxy-specific configuration using the expanded QName notation:
In this example, 'foo.bar' is a reverse package name of the BookService proxy class.
Similarly, for WebClients you can do:
In this example, 'http://localhost:8080' is the base service URI.
Please see jaxrs-https-client1.xml and jaxrs-https-client2.xml configuration files for more examples.
Also see this wiki page on how to configure HTTPConduits.
Proxies and HTTP-centric clients can have the HTTP Authorization header set up explicitly:
or by providing a username and password pair at client creation time, for example:
When injecting clients from Spring, one can add 'username' and 'password' values as attributes to jaxrs:client elements or add them to WebClient factory create methods.
Please see JAXRSClientSpringBoot documentation on how CXF JAX-RS Clients can be used in a SpringBoot Application.
