Why the slow WADL uptake? [closed]

Question

I've been researching WADL and am wondering why it isn't more widely adopted?

With the rate at which REST usage seems to be growing, I'm surprised that more development efforts don't use it.

Is there are fundamental flaw in its design, is it not a good match for the culture that typically surrounds RESTful web services, or is it something else entirely?

Marlin

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 :-) )

Tongue

I don't agree that interop is "free" when using REST. REST doesn't magically provide interop, not in the way a WADL would hope to provide. I recognize that there are interop challenges (some call it "impedance mismatch") when mapping from, say, an XSD into a Java class, or from XSD to C#. But that is not necessarily true of all such mapping approaches. XSD in particular is waaaay more complicated than it needs to be in order to support the 80% interop case for web services. If WADL is appropriately modest in its goals, it could provide real value, with low risk of pitfalls. – Quintuplet

I agree with Cheeso, REST doesn't provide anything 'for free'. You still have 'some work' to do to ensure you are dealing with apples (and not oranges) particularly with data payloads (whether HTTP is there or not). REST also imposes issues when mapping to different 'languages/tool-set' targets. This introduces even further opportunities for impedance mismatch between two endpoints (particularly when each endpoint are not under a single point of control). – Malvie

I do not think that this is the reason behind low adaption (In fact I can argue on the validity of this reason as well, that apart). The reason for low adaption of wadl in my understanding would be, it usage in the architecture of whole solution. Very few people think REST and Enterprise SOA together. REST Services are often placed on frontends for JavaScript or Mobile Apps to consume. The adaptation of REST in MicroServices SOA architecture is small but growing, this would push for things like WADL and auto client generation. – Isidore

Agree with @Quintuplet (and gto406) Sentence "Nothing in REST is for Free" is copyrighted, or copy-left? ;) Simple, nice (like say followers) rest have software problem too, first in my mind: Date problem in MS REST/JSON libraries (encoding special chars in amateur naive implementations the next) – Kellda

I am surprised I am still getting comments on this answer... do people noways still considering WADL? – Tongue

The lack of client generation is a bummer :( – Glint

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.

Staphyloplasty

Curious what people think these days given the popularity of things like "Swagger". – Ibbetson