Spring http client6/1/2023 Websockets Support for the Websockets extension to the HTTP spec. Transparent content compression/decompression Whether the client can perform compression and decompression of content via (most commonly) Deflate, GZip or Brotli without requiring the caller to explicitly perform the encode and decode steps.Īt present GZip is by far the most common algorithm.Ĭaching Support for caching of HTTP responses according to the caching elements of the HTTP standard. 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. Multipart request and file upload Support for sending multipart requests to the server.Īs with forms, we’re interested in whether the client provides an API specifically for this.Ĭookies Receives, stores, sends and allows manipulation of cookies.Īuthentication Support for HTTP authentication protocols. 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. HTTP/2 Support for version 2 of the HTTP protocol.įorms Support for posting of form data to the server. It’s worth pointing out that although most clients with an asynchronous API only support one style (futures or callbacks typically), there are a number of wrapper libraries such as Square’s Retrofit or Spring’s WebClient that adapt these to other styles such as reactive streams. 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. asynchronous API 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.
0 Comments
Leave a Reply. |