This means that a) they can only be set globally per running JVM, and b) they are much harder to integrate with other configuration systems.

Proxy server address and authentication settingsĪ further characteristic to be aware of is that some clients (specifically the core Java ones) only expose certain parameters as system properties.

Pooled connection limit - overall and per destination/route.

However, there are a few settings that are likely to be of interest to most teams (at some stage): The potential range of configuration options for an HTTP client is large, and some of the clients discussed here offer very fine-grained control over both high and low-level aspects of their behaviour. Support for the Websockets extension to the HTTP spec. Support for caching of HTTP responses according to the caching elements of the HTTP standard. Without requiring the caller to explicitly perform the encode and decode steps.Īt present GZip is by far the most common algorithm. Whether the client can perform compression and decompression Transparent content compression/decompression While all of the clients discussed can in principle support any authentication scheme by allowing setting of request headers and request parameters, only some offer explicit extension points into which authentication implementations can be plugged, and fewer still offer common schemes out of the box. Support for HTTP authentication protocols. Receives, stores, sends and allows manipulation of cookies. Support for sending multipart requests to the server.Īs with forms, we’re interested in whether the client provides an API specifically for this. Note: all clients can do this if you’re willing to build up the request from scratch yourself, so what we’re really talking about here is whether a specific API is provided. Support for posting of form data to the server. Support for version 2 of the HTTP protocol. Such as Square’s Retrofit or Spring’s WebClient that adapt these to other styles such as reactive streams. Style (futures or callbacks typically), there are a number of wrapper libraries It’s worth pointing out that although most clients with an asynchronous API only support one In practice, this is one or more of futures, callbacks or reactive streams. We also indicate what style (or styles) of async API is presented, if any. Whether the client supports a synchronous (blocking) call style, asynchronous (non-blocking) or both. documentation, the following features can easily be described in yes/no form and are summarised for each client in the table below. While some factors are somewhat qualitative e.g. The last three of these are deep topics in their own right, and we’ll write more about these in future articles. Operability, reliability and observability.Obviously, each project’s requirements are somewhat unique, but there are several common factors that most teams would wish to consider: So what should we consider when choosing an HTTP client? We’re only going to discuss clients that actually implement the HTTP protocol, so libraries such as Spring’s RestTemplate or Feign that act as higher-level wrappers will not be discussed (although we may look at these in a future article). This article aims to provide an overview of the major libraries, with a focus on the characteristics you’re likely to care about when making a selection for your project. This can make choosing the right HTTP client less than straightforward.

HTTP has become the dominant protocol for integration of networked programs, and consequently many (possibly most) Java projects need to be able to make HTTP calls to other systems.Īs with many things in the Java ecosystem, a broad array of alternatives exist for achieving this, both via core libraries and open source.

Java http client library