By sandoz on Dec 12, 2007
Current stable versions of Jersey require an awkward tool time step to identify the set of root resource classes and then generate a WADL document, from that set, that is accessible from the Web application.
For the next release, 0.5, everything will be dynamic. And we have just finished adding dynamic WADL support to the trunk. So the same URI, <base URI>/application.wadl, to access the WADL of the Web application is supported but no tool-time configuration is required. There is a runtime requirement that the JAXB jars be in the class path, if not then WADL support is turned off but the Web application will still work.
In addition there is experimental support for GETing the WADL of a specific resource. At deployment the runtime only knows about root resource classes but a Web application can dynamically return other resources. This allows a client to GET WADL for such resources enabling the client to "WADL" through the resources :-) I like this approach, it fits more closely with the view of WADL as hypermedia and using WADL in a much more loosely coupled way rather than a way to describe the whole Web application.
Currently WADL is obtained by a client performing a GET request on a URI and setting the Accept header to include the media type "application/vnd.sun.wadl+xml". I am not sure i like this approach as it can interfere with application specific GET methods (it is implemented so application specific GET methods take priority, thus WADL may not always be returned).
Two other approaches may be more appropriate:
- Return WADL as the representation of HTTP OPTIONS response. The OPTIONS method is automatically supported to return the allowed HTTP methods in the Allow response header.
- Return WADL using a sub-resource, say "/application.wadl".