Gérald Quintana wrote:
> Hi Paul,
>
> Happy new year!
>
Happy new year to you :-)
>>> Question 1: I wondered whether it was possible to generate WADL
>>> descriptor from Java sources using an Ant script or command line tool?
>>>
>> Would you be interested and have
>> time to help out on developing such an ant task? My knowledge of the ant
>> API is limited...
>>
> Sorry but I don't have a lot of free time and my Ant knowledge is
> limited to using it.
>
OK. No problem, i will look into it.
>> Note that such static analysis will not necessarily get all the WADL for
>> all resources you have implemented. If all resources are root resources
>> then it will work, but if you have root resources that return
>> sub-resources then no WADL will be defined until those sub-resources get
>> instantiated i.e. the whole application cannot be know at compile time.
>>
> It's a pity that sub-resources can not be identified by tooling.
>
It can but not at compile time :-) The sub-resources feature
(specifically sub-resource locators) allow one to build very dynamic
services using polymorphism built into the Java language so that it is
not possible to know things using static analysis.
The constraints of the REST style go to great lengths to avoid tight
coupling of clients and services which is very much contrary to that of
RPC or WDSL based approach. The more you application specifics you
describe upfront (and also require of a client to know) the more
dependencies your clients will have and therefore are more likely to
break in the future, the harder it is to mash up, the harder it is to scale.
>>> Question 2: I saw that NetBeans 6 + JAXRS plugin was able to generate
>>> a Java Script Client. I wondered whether a tool to generate JavaScript
>>> stubs existed (wadl2javascript or something like that)
>>>
> If JavaScript stubs could be generated, it would make the development
> of AJAXified web applications a bit easier. We could use JAXRS
> resources as RPC services to get/push data from/to server. Well, it's
> just an idea...
>
IMHO i would avoid trying to think in terms of RPC (where the method is
in the message and not the HTTP method) when building a RESTful Web
services and instead think about resources with a uniform interface and
how those resources connect together through links in the representations.
You may find that your operations of get/put data from/to the server map
very naturally to a resource(s) with GET/PUT/POST methods implemented.
If seen in that light the necessity for an application-specific API to
access the resources may not be so important, since every resource has a
uniform interface. This makes it much easier for various type of client
(like the browser or curl) to consume bits of the service without having
to know, or care, how all the service is specified.
If you generate code i presume you will be writing application or test
code that depends on that generated code. This creates an additional
layer of a static dependency. I think what is perhaps missing is a
better *generic* client side HTTP API (perhaps using WADL underneath the
covers to help out).
For the next release of Jersey, 0.6, we will have a generic client side
API that should make it easier to access resources using the uniform
interface approach. We are already using this API for the unit tests and
it has proved very useful to develop tests without having to generate
any client-side code.
Paul.
> Thanks for your answers,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109