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
2 comments:
"having reliable interfaces at design time is a bad thing "
no doubt that it is a good thing. But that doesn't make it right to do. Bind the clients at run time, but try and force people to keep their interfaces standard and reliable. The whole promise of SOA is that you define your set of services, and then quickly change or tie them up any which way you want . You can make new services that do the same thing, or move to someone that gives you the same service cheaper etc. etc. You know the "Why businesses need SOA - 101".
see http://www.mnot.net/blog/2008/01/21/wadl_watching for some nice thoughts too.
"No doubt that it is a good thing. But that doesn't make it right to do"
Err yes it does :)
The myth of SOA 101 is like Physics 101... its fine to get you hooked but in the long run its just a mental stepping stone.
If you are doing VMI with 20 suppliers then most of the time is not going to be spent in adding a new supplier to the technical part, its going to be in negotiating the contracts and setting up the billing/invoice arrangements, personal contacts and pricing agreements.
Changing commercial services is a legal switch, not just a "what is cheaper" technology driven decision.
If however everyone agreed to the same semantic interface (HTTP does syntax) then it would be even easier to switch than in a dynamic environment... this is why mobile phones can work globally.
Post a Comment