HTTP client API

[Michael McMahon]

Hi Anthony,

On 08/09/2016, 18:49, Anthony Vanelverdinghe wrote:
> Hi Michael
>
> What's the rationale for not turning all public classes into 
> interfaces, since none of them contain any actual implementation code?
>
We could do that with little or no impact on the implementation or on 
calling code.
I will look into it.

> 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?
>
There was a desire expressed for the concept of a default priority, 
which would not have any impact on client
behavior, but could still affect the behavior of the server. Client 
applications might be able to differentiate
requests with different priorities by using different HttpClient instances.

> 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>>
>
Agreed on both points.

One other thing. I just want to acknowledge, since I haven't before, the 
work you did, prototyping
the change to the request and response processor API, and the use of the 
Flow Publisher and
Subscriber classes in particular. I think that has been a very useful 
addition to the API.

Thanks,
Michael
>
> 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] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>>
>> [2] 
>> http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout.1/package-summary.html
>>
>> 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 oracle.com <mailto:michael.x.mcmahon at oracle.com>> 
>>> 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] http://cr.openjdk.java.net/~michaelm/httpclient/api/
>>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/api/>
>>>
>>>     [2]
>>>     http://cr.openjdk.java.net/~michaelm/httpclient/specdiffout/package-summary.html
>>>     <http://cr.openjdk.java.net/%7Emichaelm/httpclient/specdiffout/package-summary.html>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160912/4b0b8f76/attachment-0001.html>