Http client API

[Chris Hegarty]

On 09/08/12 06:10, Sean Chou wrote:
> Hi Chris,
>
>       That's exactly my concern. I agree this provides best flexibility
> and content convenient methods are not proper in this API. So, is there
> going to have content specific convenient APIs like java.nio.file.Files
> ? Although it is a wrapper, it may be useful and intuitive, and easy to
> use for those who just want to open a webpage but don't want to know
> request and response. And as well doesn't break modularization. Thanks.

I think it is certainly worth some consideration, but exactly where it 
would reside and how it could be specified without "breaking" modularity 
is a bit of a conundrum. Most of the types that would be useful to have 
in such a wrapper/convenience/utility API will come from modules that 
are not from the same module as the httpclient will most likely be 
targeted to. So any API will have cross module dependencies ( not 
necessarily a problem ), just need to think through the implications.

-Chris

> On Wed, Aug 8, 2012 at 5:52 PM, Chris Hegarty <chris.hegarty at oracle.com
> <mailto:chris.hegarty at oracle.com>> wrote:
>
>     On 08/08/2012 07:25, Sean Chou wrote:
>
>
>         Is it possible to have methods like
>
>         public abstract HTMLDocument getResponse(String request)  in class
>         HttpClient ?
>
>
>     Hi Sean,
>
>     I think what you are suggesting is content specific convenience
>     methods, something akin to URLConnection.getContent(), right? In my
>     experience, this type of interface can be a little problematic and
>     not all that widely used.
>
>     I'm personally not in favor of such convenience methods. I can see
>     their potential value, but this would appear to be a low level API
>     and I don't think it should favor one specific content type over
>     another.
>
>      From my reading of the API it exposes various methods to access the
>     response body. It is quite easy to wrap one of these in a content
>     specific parser. For example, for xml you could do
>
>        XMLInputFactory xif = ...;
>
>     xif.createStreamReader(client.__getResponse(request).__getBodyAsInputStream());
>
>       OR
>        SAXParserFactory spf = ...;
>
>     spf.newSAXParser().parse(__client.getResponse(request).__getBodyAsInputStream(),
>     handler);
>
>     I think this gives the best flexibility without favoring one content
>     type parser, or one programming model, over another.
>
>     Does this make sense? Have I missed the point of your proposal?
>     Maybe others have a different view...
>
>     -Chris.
>
>
>
>
>         On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon
>         <michael.x.mcmahon at oracle.com
>         <mailto:michael.x.mcmahon at oracle.com>
>         <mailto:michael.x.mcmahon at __oracle.com
>         <mailto:michael.x.mcmahon at oracle.com>>> wrote:
>
>              Hi,
>
>              A new revision of the Http client API planned for jdk 8 can
>         be viewed
>              at the following link
>
>         http://cr.openjdk.java.net/~____michaelm/httpclient/v0.3/
>         <http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/>
>
>              <http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/
>         <http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/>>
>
>              We would like to review the api on this mailing list.
>              So, all comments are welcome.
>
>              Thanks
>              Michael McMahon.
>
>
>
>
>         --
>         Best Regards,
>         Sean Chou
>
>
>
>
> --
> Best Regards,
> Sean Chou
>