元数据驱动设计 —— 为动态移动应用创建Web API

时间回到多年之前（当时我的头发还没这么稀疏），Google在4月1日这一天发布了Gmail，这不由得令许多人怀疑这个产品是否只是Google精心炮制的一个玩笑。但谁又能够去指责他们的怀疑呢？毕竟整个互联网行业还不够成熟，它仍然停留在青春期阶段。甚至Web API服务器在当时也是一门新生的技术。在当时，许多不同种类的机器之间的远程调用仍然时常会通过由服务器生成的过程桩进行“握手”的方式以实现通信（例如CORBA）。

\\

差不多在同一时间，软件架构师Kevin Perera在他当时所参与的项目中找出了通信层的一种模式。为了简化这种风格的架构以及具体实现中的构建过程，他提出了一种全新的设计方法作为此问题的解决方案¹。他将其称为“元数据驱动设计与开发”，这种方法能够将设计与开发整合起来，并通过一种客户端-服务器的软件开发范式将两者统一起来。他通过一个示例表明，通过几行元数据，就能够描述某个服务以及它所暴露的方法。并且它的抽象层次比起接口定义语言（IDL）更高，因此可以使用同样一套元数据去驱动整个分布式系统的构建、交互以及遍历。如果开发者需要为服务加入一个新的方法，所需的工作只是加入几行新的元数据，以及必要的少部分代码更新而已。服务端只需使用一些简单的功能与数据结构，而不必对它的接口进行任何后续的变动，因为元数据能够有效地承担交互的契约。作为元数据设计的早期追随者，Perera的努力让整个软件社区的目光投向某个简单却新颖的思想：只需将软件的设计进行更进一步的抽象，我们就能够创建出这样一种解决方案，它能够允许设计上的各种改进同时进行计划与实现。虽然这个方案是10年之前所提出的，但它的优点却延伸至今。

\\

那么，元数据驱动设计究竟是什么？简单地说，可以将其总结为一种软件设计与实现的方式，而元数据可以构成并整合开发过程的这两个阶段。在我之前所发表的一篇文章中²，我曾经描述了如何使用元数据驱动设计（MDD）方式以设计出一种引擎，让它从某个API服务器中获取数据。现在，我们将从那一场景中提取出相同的核心思想，并表明MDD是怎样帮助我们为某个API服务器打造一个现代化的架构，尤其是用于iOS移动应用的服务端架构的。

\\

虽然我在移动应用开发领域称不上专家，但也多少有所涉猎。在创建基于iOS和Android这些平台上的应用时，我特别留意了在原生应用开发过程中额外增加的一部分时间，尤其是与开发桌面应用相比所增加的时间。除了应用本身的用户交互性要进行大量的测试之外，还有很大一部分时间是在使用一些更为复杂的框架（例如Cocoa）时对应用的导航控制流进行组织的时间。当然，还有将应用提交审核的等待时间，以及根据应用商店管理者的要求和用户的需求而对应用进行后续修改及调整所需的时间。（仅举一例，我刚刚才知道在应用中不能够将某个特性命名为“魔法8球”（Magic 8-Ball），因为美泰公司（全球最大的玩具公司）会认为你侵犯了他们的商标。这种事谁会知道啊？！）。如果将这些时间与精力都计算在内，那么结果就很明显了：为了简化这种应用的维护与更新，你必须投入巨大的精力。在几个小时的开发工作之后，我就意识到，如果有某种方式能够动态地更新应用的数据与行为，将带来很大的益处。而如果我能够对应用进行配置，让它的行为由元数据库所驱动，那我就能够减少在进行各种变更时所必需的投入。事实上，客户端代码能够向某个API服务器请求这些元数据，通过在这些返回的元数据中实现变更，我就能够避免将更新的应用提交给对应的应用商店的过程了。更妙的是，我同样能够使用 MDD的方法设计API的服务端&#x