HTTP client API

[Tobias Thierer]

On Thu, Oct 27, 2016 at 7:19 PM, Anthony Vanelverdinghe <
anthony.vanelverdinghe at gmail.com> wrote:

As far as I know, the latest published Javadoc is at [1] (which was linked
> to in [2]). However, this Javadoc doesn't exactly match the current code
> either.
>

Thanks for the updated links and for your responses below! Further comments
inline below - I'm keeping some bits brief since I just responded to
Michael's email as well, I might write more later.

> one thing I found particularly challenging was the control flow
> progression [...] because it is push based and forces an application to
> relinquish control to the library rather than pulling data out of the
> library.
> The application is still in control by means of its Flow.Subscription (see
> Flow.Subscriber::onSubscribe), isn't it?
>

When I said "*in control*", I meant that the flow of execution is
controlled by loops, if statements etc. in application code, as opposed to
the application needing to *react* to the library deciding to call some
callbacks.

The former API tends to be easier to use and debug, the latter might allow
better performance (throughput/latency). How are you driving the trade-offs
in this area?


> > asByteArrayConsumer(Consumer<Optional<byte[]>> consumer): Why is this
> an Optional? What logic decides whether an empty response body will be
> represented as a present byte[0] or an absent value?
> As the Javadoc says, it's an Optional to be able to mark the end of the
> body. In case of an empty response body, the Consumer will therefore
> receive an Optional.empty() value.
>

How is it easier for an application to handle the special value of an
Optional.empty() to signify the end of data than it would be to handle
null? It seems like the absent/empty Optional just becomes another kind of
null here - you're just replacing NullPointerException with
NoSuchElementException.

2.) what happens when name is null, is specified by the following note in
> the package Javadoc: "Unless otherwise stated, null parameter values will
> cause methods of all classes in this package to throw NullPointerException."
>

Ah, thanks, I had missed that.

3.) allowing custom redirection policies was brought up before [4][5],
> proposing that a redirection policy would simply be a
> BiFunction<HttpResponse, Integer, Optional<HttpRequest>>. Besides, analog
> to e.g. java.nio.file.StandardOpenOption, there would also be a
> StandardRedirectionPolicy enum [6].
>

That makes sense. Has anyone considered an abstraction along the lines of
OkHttp's Interceptor <https://github.com/square/okhttp/wiki/Interceptors>?
I don't know how well they would interact with the Flow API, but it's a
simple API with versatile uses such as:

   - redirects (potentially replacing the Redirect abstraction)
   - early abort based on headers or response code (potentially replacing
   the BodyHandler abstraction)
   - logging (potentially offering additional functionality)
   - ...

?

4.) it doesn't, as is specified in HttpClient.Builder::version
>

Per my other response to Michael just now: Given that
HttpClientBuilder.version(Version) does not actually restrict the client to
only that version, should it perhaps be called setMaximumVersion(Version),
or changed to enableVersion(Version) / disableVersion(Version), or similar?

5.) this was brought up in [7], and was addressed, I believe, in the latest
> API [1] by replacing CookieManager with java.net.CookieHandler. However,
> this change isn't in the current code (yet?).
>

Ah, interesting. I look forward to seeing if CookieHandler can be tweaked
to allow RFC 6265 cookies.

Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20161031/37ab6705/attachment.html>