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.mcma...@oracle.com <mailto:michael.x.mcma...@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>
