On Feb 10, 2010, at 7:56 AM, Jan Algermissen wrote:
>>>
>>>> And one area of definite controversy is the client proxy will utilize WADL, dynamically via OPTIONS, to obtain additional meta-data e.g. to know if a name corresponds say to a query parameter or say a form parameter. As i said this is experimental :-)
>>>
>>> I think WADL can maybe be a good tool for server side code generation but exposing WADL to the client violates the hypermedia constraint and should be discouraged. (Paraphrasing Roy) all of REST's descriptive effort should be spent in media type and link relation specifications.
>>
>> The WADL exposed by Jersey in no way violates the REST constraints. A violation will only happen if the client uses it the wrong way (for example statically generating code for resource types), which is true of any hypermedia exposed by a service.
>
> Ah, you are using the WADL as a form at run time, yes? Guess I missed that. OTH, I still think it is just overhead because the media type can say all this. It feels enterprisey :-)
>
> IMHO there should be more focus on the media type design activity (which is *the* central thing to do). I think that the proposed approach leads developers to focus on the technical instead of 'document design' layer. But I'll look into that further.
>
The real difficulty here is that we don't want to tie the client-side framework to one (or more) specific media types. Doing so would be much easier but we want a general-purpose client-side framework suitable for most existing and future media types. Because of this we need something to provide additional metadata that identifies the links in the returned representations and runtime-generated WADL fits the bill nicely.
Marc.