Hi,
I say your blog here:
http://kingsfleet.blogspot.com/2009/09/javalangreflectproxy-client-based-on.html
Interesting. I think this is worth pursuing further.
IMHO think we need a HATEOAS concept for JAXB (or for any model?) that
can work on both the server and client side.
Lets hope these ideas can transfer from your laptop into a branch of
Jersey and then into the trunk :-)
On Sep 7, 2009, at 2:48 PM, gerard davison wrote:
>
>
> On 19:59, Paul Sandoz wrote:
>> [deletia]
>>> I can see the argument against it; but in many cases your "basic
>>> work-a-day" developer is not going to understand the finer
>>> distinctions in REST and wants a simple API to program against.
>>> This is the same thing we see with JAX-WS/WSDL where most user
>>> appear to treat it as a black box.
>>>
>>> Now with Jersey, as it currently stands, we can at least generate
>>> some JAXB files for the user if we expose the grammar using the
>>> WADL extension. I do wonder if this should be the default as it
>>> would make tooling much each to write. What is the reasoning
>>> behind not making this a default feature of the WADL generator?
>>>
>>
>> Time and TLC in this area :-)
>
> Out of interest how much work do you think would be in this area
> before it would be the default? (Just so if I can argue to apply
> some time to this problem)
I would need to look into it. Martin Grotzke contributed much of the
WADL code and Martin might be able to give a better estimate that I.
> Even if we ignore the "proxy" issue for the moment this would still
> be a big help to any client to be able to have some description of
> the data model. There seem to be a feeling that you can do without a
> data model design when doing REST; but from my rather limited
> understanding so far this is not the case.
>
> Also in this area is supporting a default transform such as http://aruld.info/jersey-103-improves-wadl-support/
> be possible as it makes WADL so much easier to read. Is this just a
> lack of time thing again?
>
Time!
>>
>> What i would really like to see is the following tooling: having
>> docs and code completion with the Jersey client API based on
>> dynamic analysis of WADL obtained from the service. It could even
>> provide snippets of template Jersey client code that one could copy
>> and paste. The nice thing about this is it will work with any
>> service that provides WADL (e.g. Zembly uses WADL a lot for
>> consuming services and that WADL could be reused).
>
> Now that is very interesting and very doable as fluent APIs are
> particularly readable from a tooling point of view. This could be
> possible, the only problem is there is currently no connection
> between the WADL the and Client Code insight for a particular
> WebResource. You would need to have "eyes" on the creation of the
> Client or the @WebResourceRef that contains the resource URL and
> then the tool could then just call "OPTIONS" to get the structure of
> the resource/application in question. Would this generally work for
> REST services or just for Jersey implemented applications?
>
In terms of OPTIONS just Jersey. Jersey also provides WADL for
statically known resources at a well-defined location which i guess
could be generalized not to be Jersey specific.
Paul.