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，我们专心做其他技术细节。
