引子
在早期的淘宝 TMS 页面搭建系统中,为了解决页面模板和数据的分离问题,机智的先知们扩充了一系列灵活的 PHP 标签函数,得以将数据的定义从模板视图中解耦出来。以其中一个最为常用的函数为例:
1 |
_tms_custom('{"name":"TextLinks","title":"文字链接","group":"文字链接","row":"10","defaultRow":"5","fields":"text:文字:string,href:链接地址(URL):href"}'); |
当调用 _tms_custom(...)
函数并传入指定格式的 JSON 参数,交由翻译引擎处理后,会构建出这样的编辑表单:
而通过编辑表单录入的数据,最终会在页面中以 PHP 数组的形式填充和占位:
1 2 3 4 5 6 7 8 9 10 |
array(5) { [0]=> array(2) { ["text"]=> string(6) "淘宝网" ["href"]=> string(22) "http://www.taobao.com/" }, ... } |
从标签函数到数据对象的运转流程,可以用一张图简单予以概括:
这种模板和数据分离的方式,在早些年那是相当先进的。它用简单的语法,描述了模板所需的数据格式,还可以根据标签定义,直接构造出模拟数据,方便在开发阶段使用 “标签 + 模拟数据”
的方式调试页面。
从 描述数据格式、 构造模拟数据 的角度,这和我们要谈的 JSON Schema 不谋而合。我们用 JSON 格式来重写数据对象,应该是酱紫的:
1 2 3 4 5 6 7 |
[ { "text": "淘宝网", "href": "http://www.taobao.com/" }, ... ] |
如果用 JSON Schema 语法描述这份数据,可以完全替代标签函数的方案。这也正是淘宝 TMS 页面搭建系统在数据这块的演化过程:即从使用标签函数定义数据的方式,转变为使用 JSON Schema 描述数据。
什么是 Schema?
当我们在描述 文字链接
的时候,需要约定数据的组织方式,比如,需要知道有哪些字段,这些字段的取值如何表示等,这就是 JSON Schema 的来源。
我们以 文字链接
为例,它对应的 JSON Schema 大概如此:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "type": "object", "properties": { "text": { "type": "string", "title": "文字" }, "href": { "type": "string", "title": "链接地址(URL)" } } } |
JSON Schema 定义了如何基于 JSON 格式描述 JSON 数据结构的规范,进而提供数据校验、文档生成和接口数据交互控制等一系列能力。它的特性和用途,可以大致归纳为以下几点:
1. 用于描述数据结构
在描述 JSON 数据时,如果数据本身的复杂度很高,高到三维四维,普通的标签函数已经无法表示这种层级结构了,而 JSON Schema 利用 object
和 array
字段类型的反复嵌套,可以规避掉这个缺陷。
当然,除了键值等基本信息,规范层面还提供了丰富的关键词支持,如果想通过自定义扩展字段,解决特定场景的业务需求,也是非常方便的。
2. 用于构建人机可读的文档
计算机领域有个概念叫做自描述。所谓自描述,可以理解为:文档本身包含了自身与其他文档交互相关的描述信息,不需要其他的配置文件或者额外信息来描述。
而 JSON Schema 就是自描述的,它本身就是一份很完善的说明文档,字段的含义说明、该如何取值、格式的要求等都清晰明了。
3. 用于生成模拟数据
通过标签函数生成模拟数据,只能解决基本的格式要求。比如 string
类型的字段,模拟出来的数据,无非是一个随机字符串。
但在 JSON Schema 中,由于字段的描述不仅仅是类型,更多的约束条件,可以确保模拟数据更接近于真实数据。
4. 用于校验数据,实现自动化测试
接口数据的校验工作,往往依赖于测试代码逻辑和用例。如果用 JSON Schema 描述一个数据接口,就不需要再编写测试代码了,所有的逻辑都可以移植到 JSON Schema 中维护。配合 jsv
、tv4
等二方校验工具,接口测试可以真正自动化。
基本约束
在 JSON Schema 的世界里,一个空对象,可以描述和校验任意形式的 JSON 数据:
1 |
{} |
下面的三份数据,如果用空对象来校验的话,都是符合要求的:
1 2 3 |
250 "我是一个字符串" {"code": 200, "data": "", "message": "呵呵"} |
当然,如果这么玩的话,JSON Schema 就完全没有意义了。
type 关键字
所以,我们需要使用 type
关键字,将 JSON Schema 限制为特定的数据类型。比如下面这个 JSON Schema 描述,只有字符串类型的数据,才能顺利通过校验:
1 |
{ "type": "string" } |
可以校验通过:
1 |
І数据的定义从模板视图中解耦出来。以其中一个最为常用的函数为例:
当调用 而通过编辑表单录入的数据,最终会在页面中以 PHP 数组的形式填充和占位:
从标签函数到数据对象的运转流程,可以用一张图简单予以概括: 这种模板和数据分离的方式,在早些年那是相当先进的。它用简单的语法,描述了模板所需的数据格式,还可以根据标签定义,直接构造出模拟数据,方便在开发阶段使用 从 描述数据格式、 构造模拟数据 的角度,这和我们要谈的 JSON Schema 不谋而合。我们用 JSON 格式来重写数据对象,应该是酱紫的:
如果用 JSON Schema 语法描述这份数据,可以完全替代标签函数的方案。这也正是淘宝 TMS 页面搭建系统在数据这块的演化过程:即从使用标签函数定义数据的方式,转变为使用 JSON Schema 描述数据。 什么是 Schema?当我们在描述 我们以
JSON Schema 定义了如何基于 JSON 格式描述 JSON 数据结构的规范,进而提供数据校验、文档生成和接口数据交互控制等一系列能力。它的特性和用途,可以大致归纳为以下几点: 1. 用于描述数据结构在描述 JSON 数据时,如果数据本身的复杂度很高,高到三维四维,普通的标签函数已经无法表示这种层级结构了,而 JSON Schema 利用 当然,除了键值等基本信息,规范层面还提供了丰富的关键词支持,如果想通过自定义扩展字段,解决特定场景的业务需求,也是非常方便的。 2. 用于构建人机可读的文档计算机领域有个概念叫做自描述。所谓自描述,可以理解为:文档本身包含了自身与其他文档交互相关的描述信息,不需要其他的配置文件或者额外信息来描述。 而 JSON Schema 就是自描述的,它本身就是一份很完善的说明文档,字段的含义说明、该如何取值、格式的要求等都清晰明了。 3. 用于生成模拟数据通过标签函数生成模拟数据,只能解决基本的格式要求。比如 但在 JSON Schema 中,由于字段的描述不仅仅是类型,更多的约束条件,可以确保模拟数据更接近于真实数据。 4. 用于校验数据,实现自动化测试接口数据的校验工作,往往依赖于测试代码逻辑和用例。如果用 JSON Schema 描述一个数据接口,就不需要再编写测试代码了,所有的逻辑都可以移植到 JSON Schema 中维护。配合 基本约束在 JSON Schema 的世界里,一个空对象,可以描述和校验任意形式的 JSON 数据:
下面的三份数据,如果用空对象来校验的话,都是符合要求的:
当然,如果这么玩的话,JSON Schema 就完全没有意义了。 type 关键字所以,我们需要使用
可以校验通过: |