Hi,
during our last meeting we discussed possibility of implementing HTTP
client, based on Grizzly.
Hubert expressed certain interest in starting working on the
implementation, but I think we can exptect other developers to
contribute.
Some time ago we started discussion on possible API, Grizzly HTTP
client may have, we took a look at several implementations and API
they propose. Last propose we had from Paul (project Jersey lead),
pls. see mails history bellow. Here is just code snippet , with some
API proposal from Paul:
----------------------------------------------------------------------------------------------------------------------------
... it is too request/response focused and not resource focused with
the uniform interface at the fore of the API with the ability to
easily use many Java types directly for representations.
Rather than this:
Session s = new Session();
Response r = s.get("
http://www.java.net");
System.out.println(r.getBody());
//read an image
r = s.get("
http://java.net/images/header_jnet_new.jpg");
Image img = ImageIO.read(r.getBodyAsStream());
You can type that actual resource and its uniform interface:
Client c = Client.create();
WebResource r = c.resource("
http://www.java.net");
String s = r.get(String.class);
Image r = r.path("images/header_jnet_new.jpg").get(Image.class);
Or:
AsyncWebResource r = c.asyncResource("
http://www.java.net");
// Non blocking, but not efficiently implemented and no callback
mechanism
Future<Image> r = r.path("images/
header_jnet_new.jpg").get(Image.class);
------------------------------------------------------------------------------------------------------------------------
Here is Jersey client side API Paul references to [1].
IMHO this API looks quite general and could be used in Grizzly.
Will be glad to hear your opinions.
Thanks.
WBR,
Alexey.
[1]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/package-summary.html
Begin forwarded message:
> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Date: November 26, 2008 3:36:17 PM GMT+01:00
> To: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
> Cc: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
> Subject: Re: Jersey client side API
>
>
> On Nov 26, 2008, at 3:06 PM, Oleksiy Stashok wrote:
>
>>>> wanted to ask your opinion, whether it's theoretically possible
>>>> to use Jersey client side API as general HTTP client side
>>>> implementation?
>>>> In other words as replacement of HttpURLConnection?
>>>>
>>>
>>> That was the idea. It is designed to be a high-level ease of use
>>> API that leverages a lower-level API that should not really be
>>> used by the average developer. Currently HttpURLConnection is used
>>> underneath but we also have a prototype Apache HTTP client
>>> implementation as well. The advantage of the latter is there are
>>> many more features available to leverage like better caching,
>>> cookie and auth support.
>> Ok.
>> BTW, looks like Apache HTTP client is not based on Mina!?
>>
>
> Not sure, but i suspect not.
>
>
>>
>>>> I know you spend some time to work with JF on Comet related
>>>> stuff, does it mean that Jersey client side API support async.
>>>> server notifications?
>>>>
>>>
>>> Not quite yet as i would like it. There is an AsyncWebResource:
>>>
>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/AsyncWebResource.html
>>>
>>> But the implementation underneath is really dumb because there is
>>> no async support in HttpURLConnection (see end of email for the
>>> implementation).
>> Right. This is what we wanted to change with Grizzly.
>>
>>
>>>> We were asked for Grizzly based HTTP client implementation long
>>>> time ago... we even have a person, who could be interested to do
>>>> that and I'm trying to help him as much as possible.
>>>>
>>>
>>> OK. I would be great if we could work together on this. A clean,
>>> neat low-level HTTP client API with great aysnc support would be
>>> very useful but we also need to supply additional functionality:
>>> cache?, cookie, auth etc otherwise it is unlikely to get used a lot.
>>>
>>> Paul.
>>>
>>> private <T> Future<T> handle(final GenericType<T> gt, final
>>> ClientRequest ro) {
>>> FutureTask<T> ft = new FutureTask<T>(new Callable<T>() {
>>> public T call() throws Exception {
>>> ClientResponse r = getHeadHandler().handle(ro);
>>>
>>> if (gt.getRawClass() == ClientResponse.class)
>>> gt.getRawClass().cast(r);
>>>
>>> if (r.getStatus() < 300) return r.getEntity(gt);
>>>
>>> throw new UniformInterfaceException("Status: " +
>>> r.getStatus(), r);
>>> }
>>> });
>>> new Thread(ft).start();
>>> return ft;
>>> }
>>
>> Are you aware about project swingx [1].
>
> Yes, but i from high-level REST persecutive i think it is wrongly
> focused as is the Apache HTTP client API. It is too request/response
> focused and not resource focused with the uniform interface at the
> fore of the API with the ability to easily use many Java types
> directly for representations.
>
> Rather than this:
>
> Session s = new Session();
> Response r = s.get("http://www.java.net");
> System.out.println(r.getBody());
>
> //read an image
> r = s.get("http://java.net/images/header_jnet_new.jpg");
> Image img = ImageIO.read(r.getBodyAsStream());
>
> You can type that actual resource and its uniform interface:
>
> Client c = Client.create();
> WebResource r = c.resource("http://www.java.net");
>
> String s = r.get(String.class);
>
> Image r = r.path("images/header_jnet_new.jpg").get(Image.class);
>
> Or:
>
> AsyncWebResource r = c.asyncResource("http://www.java.net");
> // Non blocking, but not efficiently implemented and no callback
> mechanism
> Future<Image> r = r.path("images/
> header_jnet_new.jpg").get(Image.class);
>
>
> Once you type a resource it makes it easy to pass around, for
> example we could support injection of WebResource instances
> configured appropriately on server-side resource classes. The ideal
> underlying scenario for Glassfish is that when a server is also a
> client threads are efficiently used in either case for sync/async. I
> think it will be increasingly the case that servers will become
> clients if the RESTful approach starts gaining more traction in the
> enterprise since service composition becomes a lot easier to scale,
> support and manage.
>
> Paul.
>
>> They also have some HTTP client API, which looks quite nice [2],
>> though they don't use NIO and non-blocking either.
>>
>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>> [1] https://swingx-ws.dev.java.net/source/browse/swingx-ws/src/java/org/jdesktop/http/
>> [2] http://today.java.net/pub/a/today/2006/10/11/web-swinging.html
>>>
>>>
>>
>
