Http client API (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Thu Aug 9 03:00:26 PDT 2012

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

More information about the net-dev mailing list