We use WADL a lot at Rackspace for documentation and validation.  Description 
languages are good when you want to automate. We have dozens of complex 
internal services which we need to precisely document, validate, translate, 
etc. Doing this manually would take a fair amount of effort and would likely 
achieve inconsistent results.  We don’t expect our developers to consume our 
WADL directly, instead we create friendly documentation from it (see 
http://docs.rackspace.com) and we use it to confirm that our services are 
actually adhering to what the documentation says.

You can read more about our processes and how we use WADL here: 
http://www.balisage.net/Proceedings/vol8/html/Williams01/BalisageVol8-Williams01.html

-jOrGe W.


On Mar 10, 2014, at 8:17 AM, Bill Burke <[email protected]> wrote:

> 
> 
> On 3/10/2014 7:06 AM, Sergey Beryozkin wrote:
>> Hi
>> On 07/03/14 05:24, Gary Gregory wrote:
>>> Hi All,
>>> 
>>> I'd like to use a CXF dynamic client to call a RESTful service. I also
>>> want
>>> to formally describe the RESTful service with a standard-based file.
>>> 
>>> My first choice was WSDL 2.0 since it is a standard.
>>> 
>>> Creating a client with JaxWsDynamicClientFactory fails with a WSDL 2.0
>>> file. Is WSDL 2.0 on the roadmap?
>>> 
>>> Next up is WADL, an almost standard. I do not see any WADL samples in
>>> 2.7.10 or 3.0.0-m2.
>>> 
>>> Creating a WADL client with JaxWsDynamicClientFactory fails.
>>> 
>>> Can you please provide some guidance WRT WSDL 2.0, WADL, and dynamic
>>> clients?
>>> 
>> 
>> IMHO WADL is a better language for describing REST applications, it is
>> richer and more complete. I believe WSDL 2.0 is optimized for describing
>> WS services. I recall checking its RS binding and looking at the
>> generated code and I thought at a time it was rather limited. I think it
>> is difficult to have a single language describing adequately two
>> different styles.
>> 
> 
> I'm not a big fan of a definition language like WADL or WSDL to describe REST 
> applications.  Firstly, a well written REST API doesn't need a definition 
> language.  IMO, it encourages too much of the "old" mindset of RPC when 
> clients should be thinking more about HATEOAS and self describing messages.  
> It also seems to encourage developers to override the meaning of HTTP verbs, 
> headers, and/or status codes.   Developers should focus on human 
> documentation for their web interfaces. Javascript, Python, PHP, etc. 
> developers won't know or want to know WADL/WSDL and looking at this big W*DL 
> document can be daunting, overwhelming, or just plain confusing.  What it 
> boils down to IMO, if you feel the need to have a definition language, stay 
> with SOAP and WS-*.
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

Reply via email to