HTTP client API

Anthony Vanelverdinghe anthony.vanelverdinghe at
Thu Sep 8 17:49:09 UTC 2016

Hi Michael

What's the rationale for not turning all public classes into interfaces, 
since none of them contain any actual implementation code?

On another note, I fail to see the point of 
HttpClient.Builder::priority: as far as I understand, HTTP/2 priority 
only comes into play when multiple resources depend on the same 
resource. But since there's no way to express dependencies between 
resources, how would this be useful?

Lastly, some minor remarks: I believe the following factory methods 
should be moved for consistency
- HttpRequest::noBody --> HttpRequest.BodyProcessor::noBody
- HttpResponse::multiFile --> HttpResponse.MultiProcessor::asFiles

and that "? extends T" should be used instead of "T", in the return type 
of the following methods
- HttpResponse.BodyHandler::apply, i.e. BodyProcessor<? extends T>
- HttpResponse.BodyProcessor::getBody, i.e. CompletionStage<? extends T>
- HttpResponse.MultiProcessor::onRequest, i.e. Optional<BodyProcessor<? 
extends T>>

Kind regards,

On 7/09/2016 19:15, Michael McMahon wrote:
> Hi Wenbo,
> First, sorry for the delay in replying. We took your comments and 
> prototyped how the major ones
> might be accommodated. In particular, we did the following:
> - moved "business logic" out of HttpRequest. The methods for sending 
> requests now
>    exist in HttpClient. Given that requests are no longer associated 
> with a client and can
>    be sent through any client, this means that some properties of a 
> request that used
>    to be inherited from the client can no longer be visible in the 
> HttpRequest object,
>    but that is not a problem as far as I can see. This changes the 
> look of the sample code
>    in HttpRequest, but doesn't make it any harder to read.
> - changed some method names as suggested eg newBuilder()
> - added protected constructors to the public classes. This allows 
> alternative implementations
>    for use in mocking/test frameworks etc.
> - changed the PUT, POST, GET methods in the request builder to only 
> set the method type.
>    PUT, POST takes the request body processor as parameter. A new 
> build() method returns
>    the HttpRequest.
> - added a method to HttpResponse which returns the "final" request 
> that was sent on the wire
>    for the particular response, which might be different from the user 
> initiated request.
> I put an updated apidoc [1] and specdiff [2] up to show the changes. 
> In particular, the sample
> code described in the HttpClient docs is updated to reflect the changes.
> Thanks,
> Michael
> [1]
> [2] 
> On 26/08/2016, 07:59, Wenbo Zhu wrote:
>> Hi Michael,
>> Thanks for the update! The adoption of the Flow API is indeed a big 
>> improvement (async flow-control is very hard to get right).
>> Attached is a feedback doc on this new version. One specific idea to 
>> discuss is whether it's possible to release the new HTTP client API 
>> as a standalone library (that works on JDK 9).
>> Thanks,
>> Wenbo
>> On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon 
>> <michael.x.mcmahon at <mailto:michael.x.mcmahon at>> 
>> wrote:
>>     There is an updated version of the HTTP client API doc [1] and a
>>     specdiff [2] showing the changes
>>     proposed from the current version in JDK9 dev.
>>     The main changes are:
>>     1) The request and response processors are now based on
>>     Flow.Publisher and Flow.Subscriber
>>     2) Response bodies are retrieved synchronously with the response
>>     headers as part of the
>>         HttpRequest.response() and responseAsync() methods
>>     3) Because of the change above, to allow code to examine the
>>     headers and decide what to do
>>         with the body before retrieving it, there is a new entity
>>     called a HttpResponse.BodyHandler
>>         which is given the status code and headers, and which returns
>>     a HttpResponse.BodyProcessor.
>>         Static implementations of both body handlers and body
>>     processors are provided, to make the
>>         simple cases easy to code.
>>     We are currently working in the sandbox repository again and will
>>     have these changes
>>     in the main JDK9 dev forest soon.
>>     Thanks,
>>     Michael
>>     [1]
>>     <>
>>     [2]
>>     <>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the net-dev mailing list