架构妄想

William Vambenepe 的最新文章，AJAX + REST 是最新的架构妄想，让我们回想起了一个具有 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（如GWT风格）创建 / 生成单独的 REST API？一方面，这种方法简化了 UI 实现；另一方面，每个 UI 都要有一个新 API。这种方法的伸缩性更好吗？哪个代价更高？实现 UI 集成，还是后端 API？由这个帖子还产生了另一个更严肃的问题：什么是正确的设计方法？先实现后端 API，然后设计多个使用它的 UI；还是开始从 UI 开始设计，然后再定义支撑它的 API？传统来看，API 实现的代价似乎更高，但 API 本身要比 UI 更稳定。

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

查看英文原文：Architectural Mirages