In his new post, AJAX+REST as the latest architectural mirage, William Vambenepe reminds us about a 15 years old vision that was supposed to revolutionize Web:
In that vision, your Web server would return an XML file with all the data; and alongside that XML, an XSLT (which describes how to transform the XML into HTML). The browser would run it on the XML data and display the resulting HTML. Voila! This was going to bring all kinds of benefits over the old server-spits-out-HTML model. The XML could be easily consumed by other applications (not just humans) and different XSLTs could be used to adapt to the various client platforms.
Time went on, and this idea was never really realized. Now fast forward to Ajax:
The XML doc is still there, though it usually wants to be called JSON. The XSLT is now a big pile of JavaScript. That model has many advantages over the XSLT model... It’s a lot more flexible, you can do small updates and partial page refresh, etc. But does it also maintain the architectural cleanliness of having a data API separated from the rendering logic?
Vambenepe explains why, despite of its seeming elegance and all architectural goodies, this model is not practical in most situations:
Clients of the same service support different interaction models and it’s hard for a single API to work well for all without sprawling out of control (to the point where calling it "one API" becomes a fig leaf). But if you want to keep the API surface small, you might end up with chatty apps.
But in Vambenepe’s opinion, this is only one of many problems of this approach. The other big one that he points to is the fact that such approach:
... forgo frameworks that integrate browser code and server code... not all Web developers want to think of their client framework and their server framework as two tools. Using them as one, pre-assembled, tool may not provide the most optimal code, but may still be the optimal use of your development resources..
Despite Vambenepe’s strong arguments, his post begs the question. What is the right way? Create/Generate a separate REST API for a given UI GWT style? On one hand, such approach simplifies UI implementation; on another, it requires a new API for every UI. Is this approach more scalable? What is more expensive? Implementing UI integration or back end API? There is another serious question that arises from this post. What is the right design approach? Implementing back end APIs and then design multiple UIs using it or start your design from UI and then define supporting APIs? Traditionally it seems that APIs’ implementation is more expensive, but the APIs themselves are much more stable compared to UI.
So, yes, it seems that a single API for all purposes is an architectural mirage, but a well design small set of reusable APIs can be used a foundation of many UI (Ajax) implementations.
