It seems to me that Mule’s REST Router module, which I’ve previously blogged about, is gaining popularity as a viable alternative to the Jersey module. Yet, the REST Router has a serious limitation in that it’s unable to generate a WADL: the REST equivalent of a WSDL. Recently, I had to overcome this limitation owing to a customer requirement for producing client code from the WADL.
Consider the Mule config below:
The REST Router processes HTTP requests that have a URL path matching the templateURI pattern attribute. Non-matching requests are ignored by the router and passed on to the subsequent message processor which in this case is a static component. Each nested block in the router corresponds to an HTTP method. A GET request is processed by the rest-router:get element, a PUT request is processed by the rest-router:put element, and so on.
WADL generation isn’t a feature supported by the REST Router. If I was using the Jersey module in this example, I’d get the service WADL on hitting the URL http://localhost:8081/application.wadl. Although I’d like to avoid using Jersey for various reasons, I could leverage the library’s WADL generation feature:
The above modified Mule config routes WADL requests to Jersey and all other requests to the REST Router. Upon receiving a WADL request, Jersey returns the WADL derived from the JAX-RS annotated org.ossandme.CommentResource. CommentResource describes in Java the same RESTful interface described by the REST Router. Since all service logic is performed by the REST Router, I implement the resource as a Java interface instead of a class:
This example is a Maven project hosted on GitHub. To run it, (1) open your console and enter from the project root’s directory:
(2) Then deploy the package on Mule 3.3.x standalone runtime. Accessing the URL http://localhost:8081/application.wadl will give you the following: