记一次结构化数据的经历
发布于 3 个月前 作者 captainblue2013 673 次浏览 来自 分享

原文 http://www.lanhao.name/article/305

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循环起来,

遇到对象,就让SourceSchema递归进去,

对,递归是重点。

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

4.立竿见影的好处

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

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

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

回到顶部