Architecture delusion: Ajax + rest

In William vambenepe's latest article, Ajax + rest is the latest architecture delusion, which reminds us of a 15-year-old architecture that was expected to have a revolutionary impact on the web.

In this architecture, the web server returns an XML file containing all the data. Together with XML, the Web Server Returns An XSLT file (used to describe how to convert XML into HTML ). The browser will process XML data and display the final HTML. Done! This method brings many benefits, better than the old "server-generated HTML" model. XML can be easily used by other applications (not just humans). Different XSLT can be used to adapt content to various client platforms.

Time flies, but this concept has never actually been realized. Now, we can quickly turn to Ajax:

The XML document is still present, although it is often called JSON. XSLT is now a lot of JavaScript. Compared with the XSLT model, this model has many advantages ...... It is more flexible and supports small-scale updates and partial page refreshes. However, can it also keep the architecture clear and separate data APIs from the presentation logic?

Vambenepe explains the reason. Although it looks elegant and contains all the architectural advantages, this model is not practical in most cases:

Clients of the same service support multiple Interaction Models. If they do not spread without restrictions, it is difficult for a single API to meet the needs of all these models (here, the so-called "single API ", it is actually a shame ). But if you want to make the API look concise, you may eventually get applications that interact frequently.

But in vambenepe's view, this is only one of the many problems with this method. Another major problem he pointed out is the fact of this method:

...... Abandon the architecture that integrates browser code and server code ...... Not all web developers think that their client framework and Server framework are two sets of tools. Using them as a pre-assembled tool may not get the best code, but it may still be able to make the best use of your development resources.

Despite strong arguments from vambenepe, his post is still under question. What is the right path? Create/generate a separate rest API for an existing UI (such as a GWT style? On the one hand, this method simplifies UI implementation; on the other hand, each UI requires a new API. Is this method more scalable? Which one has a higher cost? Implement UI integration or backend APIs? This post also raises another more serious question: what is the correct design method? First, implement the backend API, and then design multiple UIs that use it. Or do you want to start designing the UI and then define the APIs that support it? Traditionally, API implementation costs seem to be higher, but the API itself is more stable than the UI.

Therefore, it is true that a single API that meets various needs seems to be an architecture delusion. However, a group of well-designed, lightweight, and reusable APIs can be used as the basis for many UI (Ajax) implementations.

View Original English text:Architectural mirages