This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

WADLing in Jersey

Stefan Tilkov,

Marc Hadley:

With the latest changes to Jersey you can now get information on such dynamic resources by GETing the resource with an Accept: application/vnd.sun.wadl+xml header that specifies that you want WADL rather than another representation. The Jersey runtime will inspect the object returned by the subresource locator and dynamically generate a WADL description.

Now WADL finally gets interesting (see also this discussion).

On December 22, 2007 9:45 PM, Tammo van Lessen said:

Hm, is this really RESTful? I’ve always thought each representation should ‘represent’ the actual state/content of a resource and not a bunch of meta data. Isn’t a WADL file another resource, a sub-resource so to say?

On December 22, 2007 10:29 PM, Stefan Tilkov Author Profile Page said:

Good point. Yes, you may be right — I’m not sure. If the WADL describes the resource sitting at X, I feel it’s reasonable to retrieve it from X. On the other hand, maybe it would be better to return a link instead.

On January 2, 2008 5:46 PM, Paul Sandoz said:

I have been toying with the three different approaches of using OPTIONS, GET or an additional URI, as presented here.

Part of the problem with the latter two is that they can either interfere with the application (what if WADL is stored as the media entry of an atom collection?) or assumes additional server-side framework knowledge (of the URI, since it seems silly to bootstrap and traverse parallel hypermedia).

The OPTIONS method seems, technically, the right approach but of course OPTIONS is to put it mildly under utilized.

Tis all still a bit experimental which is why we have currently implemented support for GET and OPTIONS.