users@jersey.java.net

Re: [Jersey] wadl access in Jersey

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 22 Jul 2009 11:46:12 -0400

On Jul 22, 2009, at 11:05 AM, António Mota wrote:

> WADL describes resources. A REST application should *not* have any
> prior knowledge of the resources other than one (or a few) publicly
> known resources accessible by a known URI. All other resources
> besides those should be opaque to the client, as it should be the
> hipermedia that for each request should indicate what resources are
> available from that point now.
>
> If I have today a public resource /myapp that returns URLs that
> point to /myapp/persons and /myapp/accounts, the server should be
> free to tomorrow change that URL to /myapp/pessoas and /myapp/
> contas, and while at it add also a /myapp/moradas.
>
> A WADL-based app will break, a RESTfull app won't. A WADL-based app
> will not be aware of a new resource providing new services, a
> RESTfull app will, providing it works with well defined media-types.
>
I depends on how you use the WADL. If a client fetches the WADL
dynamically and avoids static code generation then its no different to
any other kind of metadata. See the blog entry I linked to in my
previous message, all the WADL is doing is identifying the location of
links in representations and documenting the kind of resource they
point to.

> My point is not "don't use WADL", my point is "if your're building a
> Restish app with a limited scope of operation where you have
> control on both server and clients and you like WADL, go ahead, but
> if you're trying to build a universal accessible application where
> you don't have control whatsoever on the clients, using WADL is
> heading for a path of problems that you would not be capable of
> solve, precisely because you don't have control over the clients and
> the interpretation they've done of your WADL".
>
> I don't remember of ever needed a WADL to access a web site. I do
> however recall the problems I had using SOAP/WSDL and it strikes me
> why will someone want to do again those same errors.
>
Regardless of WADL, clients can always bookmark URIs in your
application, that's why cool URIs don't change:

http://www.w3.org/Provider/Style/URI

Web applications need a good versioning strategy.

Marc.


>
>
> Marc Hadley wrote:
>> On Jul 22, 2009, at 9:28 AM, António Mota wrote:
>>
>>> Of course, WADL does not conform with REST principles, at least
>>> because
>>>
>>> 1) creates a coupling between clients and server, and
>>> 2) publishes "concrete" URL's, disallowing the principle of
>>> "Hipermedia as the engine of application state"
>>>
>> Its not limited to "concrete" URIs and can support HATEOAS:
>>
>> http://weblogs.java.net/blog/mhadley/archive/2009/04/hateoas_with_wa.html
>>
>> Marc.
>>
>>>
>>> Naresh wrote:
>>>> Hi Suchitha,
>>>>
>>>> Suchitha Koneru (sukoneru) wrote:
>>>>>
>>>>> Hello Jersey Users,
>>>>>
>>>>> I am new to Jersey and I am trying to understand
>>>>> the concept of WADL. As per my understanding WADL for Rest is
>>>>> similar to WSDL for SOAP.
>>>>> Are wadls generated on the fly similar to wsdls?
>>>>>
>>>> Yes. It provides a description of the various resources in your
>>>> application and is generated on the fly.
>>>>>
>>>>> What is the url for accessing wadl from the webapplication?
>>>> If your application is deployed with name myapplication, the wadl
>>>> will be available at http://mydomain/myapplication/
>>>> application.wadl, assuming the url-pattern is "/".
>>>>>
>>>>> Could you please provide any pointers in this regard
>>>>>
>>>> May be you could have a look at the Jersey helloworld-webapp
>>>> sample [1] which generates the WADL on the fly. The wadl can be
>>>> viewed at [2].
>>>> [1] http://download.java.net/maven/2/com/sun/jersey/samples/helloworld-webapp/1.1.1-ea/helloworld-webapp-1.1.1-ea-project.zip
>>>> [2] http://localhost:8080/helloworld-webapp/application.wadl
>>>>
>>>> Hope this helps,
>>>> Naresh
>>>>>
>>>>>
>>>>> Thank you ,
>>>>>
>>>>> Suchitha
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>