William Vambenepe的最新文章，，让我们回想起了一个具有15年历史的架构，它曾被寄期望对Web产生革命性的影响。

在该架构里，Web服务器将返回包含全部数据的XML文件，与XML一道，还会返回一个XSLT文件（用于描述如何将XML转换成HTML）。浏览器将依此处理XML数据，显示最终的HTML。搞定！该方式将带来很多好处，优于老式的“服务器生成HTML”模型。XML可以被其他应用方便地使用（不仅仅是人类），不同的XSLT可被用来将内容适配到各种客户端平台。

　　光阴飞逝，但这种理念其实从未真正实现。现在，我们又快速地转向Ajax：

XML文档还在，尽管它通常被称为JSON。XSLT现在则是一大堆JavaScript。比起XSLT模型，这种模型有许多优势……它更灵活，可以实现小规模更新，以及部分页面刷新等等。但是，它是否也能够让架构保持清晰，使数据API与表现逻辑相分离呢？

　　Vambenepe解释了原因，尽管它看上去优雅并包含了所有的架构优点，但该模型在大多数情况下并不实际：

相同服务的客户端支持多种交互模型，若不无限制的蔓延开来，单个API很难满足所有这些模型的需要（这里，所谓“单一API”，其实就是一块遮羞布）。但若是想让API保持外观简洁，你最终可能就会得到交互频繁的应用。

　　但是在Vambenepe看来，这仅仅是该方法诸多问题中的一个。他指出的另一个大问题是该方法的事实：

……摒弃集成了浏览器代码和服务器代码的架构……不是所有Web开发者都认为他们的客户端框架和服务器框架是两套工具。将它们整体作为一个预先装配好的工具使用或许不会得到最优的代码，但可能还是可以最优利用你的开发资源。

　　尽管Vambenepe有强有力的论据，他的帖子还是遭到了质疑。什么才是正确之路？为现有UI（如风格）创建/生成单独的REST API？一方面，这种方法简化了UI实现；另一方面，每个UI都要有一个新API。这种方法的伸缩性更好吗？哪个代价更高？实现UI集成，还是后端API？由这个帖子还产生了另一个更严肃的问题：什么是正确的设计方法？先实现后端API，然后设计多个使用它的UI；还是开始从UI开始设计，然后再定义支撑它的API？传统来看，API实现的代价似乎更高，但API本身要比UI更稳定。

　　因此，没错，满足各种需求的单一API看起来是架构妄想。但是，一组设计良好、轻巧可重用的API可被用来作为许多UI（Ajax）实现的基础。

　　查看英文原文：