Why the slow WADL uptake? [closed]

Answer 1

I think the main reason why WADL doesn't gain popularity is that it might bring back to life all those problem we had with SOAP and WSDL. To me, the interoperability aspect is the single most important aspect of web-services.
By following the RESTful way of using pure HTTP standards you get interoperability "for free". Once you need a document to describe the services, there will be different client frameworks (or different servers frameworks) that will interpret this document differently. Once different frameworks auto-generate code from WADL you will have to deal with the interoperability problems again.

The lack of standards is the weakness and strength of the RESTful way, let's give the simple approach a chance. (even though we really enjoy automatic code generation :-) )

Answer 2

"REST in Practice: Hypermedia and Systems Architecture" by Jim Webber, Savas Parastatidis, and Ian Robinson mentions four concerns:

1. WADL takes a static view of the web application upfront, where the Web uses mediatypes and links for contracts
2. WADL tooling promotes tight coupling of client and service-side abstractions. Resources advertised from the service become the client’s domain model.
3. WADL offers no clues about ordering of interactions with resources it advertises.
4. WADL often duplicates the metadata that is available from the resources.

Points 1 & 2 are arguments on dynamic vs. static client bindings. When using WADL, the service implementor will need to be careful with backwards compatibility of the schema as the service changes. Without WADL, the client must be flexible in how it interprets responses.

Point 3 concerns work flow. WADL does not document the order in which APIs should be called. Both WADL and non-WADL service responses offer clues to the ordering through links if the service is implemented according to HATEOAS paractice.

Point 4 posits that HEAD and OPTIONS results can be inconsistent with the WADL definition. In practice, rarely are either of these methods implemented or used.

Many REST implementations are quick and dirty. It's easy to implement a REST service just for my use. It's when I have to create a client for a service provided by a different team that I want documentation. The more formal, the better. Code readable documentation, such as WADL, would be best.

My concerns as a client implementor are:

1. How do I discover the query parameters and headers that are supported?
2. How can I find the documentation about a request or response media type? Even if it is a IANA registered media type, I will still need the request/response schemas.