数据接口设计中遗漏的版本差异

我们在考虑数据接口的设计的时候，最容易关注的是数据本身的接口。简单点说，要哪些数据，我接口设计的时候就加入那些数据。在此基础上再考虑数据结构以及结构优化。

这些并没有什么问题。事实上，也只有考虑这些，接口才可以基本工作起来。不过，一个设计好的接口会比一般的接口多注意一些因素，一些以后可能发生变化的因素。在好的接口中，有些接口，一直不需要修改；有些接口修改了也和原有接口兼容。

一个接口一直都不需要修改，一般有两种情况：需求永远不变化；接口设计地太好了。我们几乎不敢说自己的接口设计地太好了，以致于可以肯定以后不会修改，于是我们不得不面对需求变更的问题。

对于软件A₁和软件B₁，他们之间定义了接口F₁。当需求变化后，如A升级到A₂，B软件升级到B₂，接口也变成F₂。如果我们只考虑软件A₂和B₂，那么当然没什么问题，F₂完全可以运行。

随着软件的复杂度提高，各种运行环境我们也开始必须考虑到。对于本案例中，我们应该关注A₁、B₁、A₂、B₂可能同时存在的情况，那么我们必须考虑A₁和B₂以及A₂和B₁的情况。如果版本更多，其中间的复杂度越高。

在业务编写中，相对于高版本来兼容低版本的代码还是可以编写出来的，因为它已经知道低版本的存在了。可是低版本如何兼容高版本之间呢？更何况，就算高版本能够兼容低版本，也容易让人对这类接口变得头疼。

在《跨越边界: Rails 迁移》中，针对Rails中的Migration做了一些比较深入的探讨。其重要信息在于，Rails中在数据迁移的时候，做了Migration记录。这样，程序可以根据这个记录进行迁移数据。

请关注这个不同点，系统中，将这些差异记录下来了！把这个思想应用到我们的数据接口的设计中，你会忽然发现，我们遗漏一项重要的信息。我们以往在设计接口的时候，只考虑到了A和B之间的关系，却没有考虑在第三纬度上的关系，也就是旧接口与新接口之间的关系。

这真是本文重点要提到的，数据接口设计中，应该包含版本差异信息。

简单点说，对于接口F₁和F₂来说，假设F₂是F₁的升级版本，那么F₂在设计的时候必须考虑如何和低版本的F₁兼容。设计师必须将其中的差异写入进接口信息中。

一般情况下，我们的接口变更多为：增加新表、增加新字段（我这里简单地用表和字段来描述数据。针对不同的存储格式，有不同的叫法）。很少有删除字段和删除表的。修改字段类型的做法虽然存在，但更是少之又少。

针对上面的变更，其实都可以找到一种方式来描述这些差异。一旦我们定义好这些差异，不管旧版本的程序还是高版本的程序，都可以通过这些差异来获取到自己所需要的数据。就算F₁和F₂已经不兼容，我们在接口信息中将不兼容的信息写进去，程序一下子就能发现，而不会在接口操纵到一半的时候，发生不可以预测的错误。

好的接口设计必然也是规范的设计。将这种设计规范在公司内部统一起来，就可以在此基础之上，设计出统一的接口交换程序，这个程序能够自动处理接口差异，可以想象，系统的兼容性必然上一个台阶。

认真地考虑我们系统之间的兼容性，将会给以后的维护减少很多工作量。而既然考虑了兼容性，就必须在接口设计的初期以及变更的时候，将前后版本的差异信息加入。这才是一个完整的设计。