Will WADL provide a second wind for REST uptake in enterprise?

Any one who has ever implemented a SOAP consuming client service will appreciate that the tooling for various languages is a very welcome feather in SOAP’s cap. Without the WSDL tooling that web service developers are accustomed to, a large portion of those developers would probably struggle to use the said service as the sher verbosity of the SOAP entity payload is simply overwhelming.

REST: A idealist view of the web or serious technology?

When REST came onto the scene it appeared to be met with two very different view points. The open source communities and web purists rejoiced… a resource orientated architecture which allowed them to scrap there verbose SOAP and XML-RPC service flow. However, from what I saw first-hand, the reaction from enterprise was somewhat different; namely, one of “So now we have to implement clients by hand? Sod that!”.

For a number of developers, including myself, we could see that REST was a much better architectural style for distributed computing on the web, but with ever decreasing budgets and squeezed time scales the added overhead of creating totally bespoke services - and therefore clients - was one that proved somewhat of a bitter pill to swallow.

WADL: Here to save the day?

Recently, WADL is coming to the fore as a structured way for providing description and automated development workflow for using REST services. WADL is based around similar principles to WSDL in that it provides a contract of service between service resource and the client.

If WADL can provide a robust framework for automated tooling with REST, I really think that we’ll see REST pick up a second wind of uptake in the enterprise setting. With players like Yahoo! leading by example, how long will it be before others follow suit?

Only time will tell…