0.背景

故事的背景，是源于要为第三方提供一套接口，而这套接口又是依赖于其他内部数据API。

这看起来好像有点平常，不过事情通常没有想象中那么顺利。

这问题在于，内部的API接口，正在处于一个动荡的年代，结构说变就变。有时候可能只是属性名变了，有时候甚至整块数据都不见了。

而对于一套给第三方用的接口，这是致命的。我们需要保持数据模型的绝对稳定性。

1.有哪些需要做的？

从内部API拿到数据，剔除部分敏感信息，调整一下属性名，简化一下层次结构，这就是我们这套接口需要做的东西。

以上的事情，都可以直接在代码里做的，反正简单unset一下，array_*一下，又不会太累，只要对照结构写就行。

但是开发者小蓝不会这么做!

这么做有以下不爽的地方：

• 底层API每次变动，都需要跟进编码，编码意味着可能出BUG
• 对于要产出的结构，没有一个明确的描述，只能靠代码
• 为了解决第二个问题，需要专门维护这个文档，告诉你产出是怎样的，时间长了，很容易“文(档)不对(代)码”

2.应该怎么做

针对以上几个问题的思考，我希望能实现以下的指标：

• 最大限度地不受底层API的影响，即使底层有迭代，这边接口的输出结构稳定
• 依赖一些Schema文件来描述底层数据与输出数据之间的转化关系，以及直接能表达出输出数据的结构
• 有条件的情况下，还能根据Schema直接生产数据文档，保证文档与执行结果的统一性

综上所述，我需要制定一个描述Schema的规范，以及编写一个数据转换的方法

3.实际操作

我们先来放出一个源数据的例子

$source = [
    'arr' => [
        [
            'a' => 1,
            'secret'=>'hey'
        ],
        [
            'a' => 4,
            'secret'=>'jude'
        ]
    ],
    'hello' => '!'
];

首先是Schema部分，为了简单易用，目前直接使用编程语言内部的数据类型来描述。

$schema = [
    'arr=array' => [
        [
            'a=c' => ''
        ]
    ]
];

这个Schema的含义就是：

• 首先arr这样的描述不清楚，要重命名为array
• 其次，array是个数组，里面的元素的模型只展示一个a属性，并且重命名为c
• hello这个属性，直接干掉

然后输出的结果就是：

     {
        "array" : [
            {
                'a' : 1
            },
            {
                'a' : 4
            }
        ]
    }
    

当然，Schema规则肯定不止这两条，这里只挑比较直接的说明一下。

同样的，规则可以慢慢添加，重要的是，整个体系的依托，要建立起来。

接下来就差一个转换函数了

代码就不贴了，无非就是根据Schema来读取Source的数据，

遇到数组，就让Source循环起来，

遇到对象,就让Source和Schema递归进去，

对，递归是重点。

写这个函数的过程就是，慢慢调bug，抓头发，拍大腿的过程，反正就是越来越健壮就是了。

4.立竿见影的好处

转换函数初步可用后，尝试着编写一个数据接口，包括编写Schema的时间，10分钟不到就出来了，还可靠。（按照对数据手写的话，估计半小时以上）

而且写Schema的时候，可用将大脑切换到数据模式，一门心思地想数据，这样出错的可能也低许多。

到运行稳定后甚至可以让其他人员来维护Schema，我们专心做其他技术细节。