So what's the caveat? It's the issue of when the WADL is consumed. Some Web services proponents who have taken an interest in Web based solution have been using WADL as they would use WSDL, as a design-time artifact. Using WADL this way though, is akin to developing a Web browser with built-in knowledge of, say, the Google homepage HTML form at the time the browser was compiled: if Google changes the form in a backwards-incompatible way (i.e. not just adding a new optional parameter) after the browser is deployed, then the browser will not be able to use that resource/service. Using the hypermedia constraint with WADL means that the client should consume the WADL at runtime. So be careful when choosing your WADL tooling, as some tools that try to help you, don't.
Now I have to admit to being happy at seeing the growth of WADL in the REST community (next up they can deal with policy, reliability, security and other challenging topics) but the implicit suggestion here is that having reliable interfaces at design time is a bad thing and that its much more effective to have dynamic run-time only interfaces that can change, and which you can automagically (in a vendor sense) adapt to.
The problem here is that its one of those beguiling silver bullets, suddenly lots of things that have previously been a challenge will melt away by using REST and letting everything adjust at Runtime. The problem with this approach is that it is spectacularly difficult to engineer in complex real-world applications.
Put it this way, if you are implementing VMI between twenty vendors and a manufacturer do you really want each of those twenty vendors to have their own unique spin on stock updates and ordering, do you really want the manufacturer to change the schema for its stock report but only find out at runtime? Before we get the "late validation" argument again would you really bet a million dollars on an XPath getting the right value?
Its a wonderful theory around all of this dynamism and automatic change, but writing applications that have to dynamically adapt to schema changes and corporate policies. The last bit is a kicker...
if you're developing client-side code which makes assumptions which aren't true of all resources (or server-side "APIs" which requires this of clients), then you're not using the uniform interface.
Now I've argued before on the fact that things like Invoices cannot not be deleted (they can be cancelled, but that is not a deletion) while other elements (e.g. stock identifiers) can clearly be deleted. If you make an assumption that delete is valid for an invoice then you are a muppet... but you might be using a uniform interface.
Design time interfaces and contracts are a good thing, there are thousands of successful projects and programmes that testify to the fact. Wishing reality away doesn't change this.
Design is a good thing, engineering is a good thing, early agreement reduces back-end problems and the earlier you find the problems the cheaper it is.
Technorati Tags: REST