数据合法性检测

    坦诚我们自己做的也不够好，这里只能抛砖引玉，看看大家是否有更好办法。

    我们有这么几个主要的合法性检查场景：

    • JSON 数据格式
    • 关键字段编码为 HEX（0-9，a-f，A-F），长度不定
    • TABLE 内部字段类型

    JSON 数据格式

    这里主要是 json decode 时，可能抛出异常的问题。我们已经在 一章中详细说明了问题本身以及解决方法，这里就不再重复。

    关键字段编码为 HEX，长度不定

    HEX 编码，最常见的存在有 MD5 值等。他们是由 0-9，A-F（或 a-f）组成。笔者把使用过的代码版本逐一罗列，并进行性能测试。通过这个测试，我们不仅仅可以收获参数校验的正确写法，以及可以再次印证一下效率最高的匹配，应该注意什么。

    把上面的源码在 OpenResty 环境中运行，输出结果如下：

    2. check_hex_default   times:5.1929998397827
    3. check_hex_jo    times:0.4539999961853

    引用一下 官方 wiki 的原文：

    课后小作业：

    • （1）为什么测试用例中要使用 ngx.update_time() 呢？好好想一想。
    • （2） 课后小作业：在测试用例里面加了一行 require("resty.core.regex")。试试去掉这一行，重新跑下程序。结果怎么样？

    TABLE 内部字段类型

    当我们接收客户端请求，除了指定字段的特殊校验外，我们最常见的需求就是对指定字段的类型做限制了。比如用户注册接口，我们就要求对方姓名、邮箱等是个字符串，手机号、电话号码等是个数字类型，详细信息可能是个图片又或者是个嵌套的 TABLE。

    例如我们接受用户的注册请求，注册接口示例请求 body 如下：

    1. {
    2.     "username":"",
    4.     "mobile_no":0,
    5.     "email":"",
    6.     "love_things":[]
    7. }

    对于有效字段描述格式，数据值是不敏感的，但是数据类型是敏感的，只要数据类型能匹配，就可以让我们轻松不少。

    来看下面的参数校验代码以及基本的测试用例：

    运行一下上面的代码，结果如下：

    1. ➜  resty test.lua
    3. unvalid check: false

    可以看到，当我们业务层面需要有 email 地址但是请求方没有上送，这时候就能检测出来了。大家看到这里也许会笑，尤其是从其他成熟 Web 框架中过来的同学，我们这里的校验可以说是比较粗糙简陋的，很多开源框架中的参数限制，都可以做到更加精确的限制。

    如果你有更好更优雅的解决办案，欢迎与我们联系。