Salut,
Oleksiy Stashok wrote:
> 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.
And we have an issue filled:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
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.
>
+1 (the link is broken BTW ;-)...checked manually the code :-)). We can
probably split the tasks amongst us. I will let peoples digest
https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
and we should split the task amongs us and see if we can build this
monster in different modules :-)
A+
-- Jeanfrancois
> 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 <mailto:Paul.Sandoz_at_Sun.COM>>
>> *Date: *November 26, 2008 3:36:17 PM GMT+01:00
>> *To: *Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM
>> <mailto:Oleksiy.Stashok_at_Sun.COM>>
>> *Cc: *Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM
>> <mailto: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
>>>>
>>>>
>>>
>>
>
