On Dec 3, 2009, at 7:12 AM, Paul Sandoz wrote:
>
>> This creates a proxy with a URL based on the Location header, if memory serves me right then if there is no location header null is returned, or I guess the client might throw an exception.
>>
>> I have not thought about Link headers before, ideally I guess these could be generated transparently on the server side and on the client they would just surface as accessors. How would that map to WADL though? (I am as every obsessed by the idea of wanting to generate these interfaces)
>>
>
> :-) I am not sure, need some input from Marc, on how WADL could be used/extended to support link types in headers and representations.
>
No extension required, include something like the following in the <response> element:
<param style="header" name="Link">
<link re="whatever" resource_type="#some_resource_type"/>
</param>
The WADL then defines the linked resource using a resource_type element which is just like a resource element minus the URI (since its provided by the link instead).
<resource_type id="some_resource_type">
...
</resource_type>
More detail here albeit with links embedded in representations instead of Link headers:
http://weblogs.java.net/blog/2009/04/02/hateoas-wadl
Marc.
>
>>
>>>
>>>
>>>> I am going to have to ponder that Ruby example a little bit to see if we can build something similar using Java, there are some interesting ideas there. I guess by typed you mean the "rel" value.
>>>
>>> Yes.
>>>
>>> But i think other patterns might also apply, even if they are less flexible or more coupled than typed links, using perhaps general XPathy like expressions.
>>
>>
>> Possible, will have a think,
>>
>> Gerard
>>
>>>
>>> Paul.
>>>
>>>> This should be possible using the existing mechanisms in JAXB.
>>>>
>>>> Cheers,
>>>>
>>>> Gerard
>>>>
>>>>
>>>> On 01/12/2009 09:25, Paul Sandoz wrote:
>>>>> Hi Jean,
>>>>>
>>>>> A proxy-based client-side solution has been discussed, but there is nothing implemented in Jersey to support this. Notably, Gerard Davidson has some ideas in this area.
>>>>>
>>>>> My opinion is that such proxies, as you present, unduly encourages the coupling of the client to the server and it really does not give much over utilizing the Jersey client API as of today, for example:
>>>>>
>>>>> Client c = Client.create();
>>>>> URI u = ...
>>>>> UriBuilder ub = UriBuilder.fromUri(u).path("product/{id}");
>>>>>
>>>>> ProductConverter pc = c.resource(ub.build(1)).get(ProductConverter.class);
>>>>> c.resource(ub.build(2)).put(new ProductConverter());
>>>>>
>>>>> Or creating a simple ProductResource class that encapsulates the above. Note that in your ProductResource interface there is no way the client can distinguish between XML or JSON.
>>>>>
>>>>> I think the main advantage to any proxy-based solution is in terms of documentation and especially when utilized with IDEs.
>>>>>
>>>>> What i would really like to see is a focus on proxy-based solutions for *representations* supporting typed links. That IMHO is the right place for proxying or even static code generation as the media types and link types are important types for hypermedia processing. There has been some nice work w.r.t. in Ruby:
>>>>>
>>>>> http://www.infoq.com/news/2009/11/restfulie-hypermedia-services
>>>>>
>>>>> Any exploration of the client area also needs to be coupled with solutions on the server-side for supporting typed links.
>>>>>
>>>>> Paul.
>>>>>
>>>>> On Dec 1, 2009, at 3:14 AM, Jean Aurambault wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm thinking about a way of generating automatically clients for a WS based on reflection. Could be by sharing the WS definition in an interface or even using directly a jersey annotated class... Let's say with an interface it would be something like this:
>>>>>>
>>>>>> public interface ProductResource {
>>>>>>
>>>>>> @Path("/product/{id}")
>>>>>> @GET
>>>>>> @Produces({"application/xml", "application/json"})
>>>>>> public ProductConverter get(@PathParam("id") int id);
>>>>>>
>>>>>> @Path("/product/{id}")
>>>>>> @PUT
>>>>>> @Consumes({"application/xml", "application/json"})
>>>>>> public void put(@PathParam("id") int id, ProductConverter productConverter);
>>>>>> }
>>>>>>
>>>>>> the server would implement the interface
>>>>>>
>>>>>> public class ProductResourceServerImpl implements ProductResource {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> And on the client side having something like this:
>>>>>>
>>>>>> Client client = new Client();
>>>>>> ProductResource pr = client.resource(ProductResource.class);
>>>>>> ProductConverter product = pr.get(1);
>>>>>> pr.put(2, new ProductConverter());
>>>>>>
>>>>>> Is there anything close to this available? Any thoughts?
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Jean
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
>>>> Oracle JDeveloper Web Service, Spring, Weblogic SCA Tooling Development
>>>> Oracle Corporation UK Ltd is a company incorporated in England & Wales.
>>>> Company Reg. No. 1782505.
>>>> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>>>>
>>>> Blog
>>>> http://kingsfleet.blogspot.com
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
>> Oracle JDeveloper Web Service, Spring, Weblogic SCA Tooling Development
>> Oracle Corporation UK Ltd is a company incorporated in England & Wales.
>> Company Reg. No. 1782505.
>> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>>
>> Blog
>> http://kingsfleet.blogspot.com
>