关于 Python 后端验证参数 的界限

[sichuyoudang312]

关于参数校验，后端有简单的统一校验格式，主要针对参数类型和长度，其他的又不值得统一的就用 lambda 进行校验，如下，只需

{
"name": ("名称", "optional str 30"),
"limit": ("每次获取条数", lambda x: x is None or x in range(101)),
"offset": ("分页偏移量", lambda x: x is None or x >= 0)
}

像 limit 我设置了 100 以内的数值型，offset 因为总数据可能很大，就没设置上限 , 结果测试人员 非要验证 offset 字符串，然后出现异常，我是不想改的，所以想问各位验证参数的界限是怎样的

我当然不会把“服务器异常”这种错误抛出来，我只是直接抛出 "msg": "'>=' not supported between instances of 'str' and 'int'" ，现在问题是测试不管这些错误，觉得既然只支持数值那输入数值以外的要抛出"该参数只支持数值" 这种信息，因为觉得这些信息用户也会看到，我说前端都不会传进来这样的数据，我当然就只校验部分类型了，offset 之前我是校验数值类型的，测试输入 -460，，，我真。。。

此外，我说的不是只有这一个接口，而是类似的

[undertonememorie]

voluptuous Schema 校验 规定字段类型和长度，测试人员肯定冲着搞崩你接口的心态去测试，你要保证系统的健壮性

[ClericPy]

我以前做的和 Fastapi 里用 pydantic 实现的差不多, 现在用的 Fastapi.......

[wangyzj]

marshmallow

[ipwx]

FastApi，你值得拥有

[sichuyoudang312]

@undertonememorie 我接口也想写的健壮些，文档里面写了 offset <int> <可选> 分页偏移量，默认 0，结果测试非输入字符串，那就抛异常了

[sichuyoudang312]

@ClericPy 因为这事发了帖子，发现了 pydantic，我不改了，我要去研究 pydantic

[sichuyoudang312]

@ipwx 学习了

[bnm965321]

出现异常当然要改，至少要把异常以错误的形式回馈

[also24]

offset 过大这件事，感觉应该在业务代码中处理，而不是入参时处理吧

[johnsona]

marshlallow+webargs,也是 schema 和我一起念，skema

[Vegetable]

生产服务器的所有异常都必须被捕获，无论任何情况都不能让上层报 500 Internal Error
我还以为这是后端开发的基本常识。

[guyskk0x0]

可以试试 Validr 这个库，我的用法：
https://github.com/anyant/rssant/blob/master/rssant_api/views/feed.py#L152

[SingeeKing]

“然后出现异常” 难道你的路由分发那里没有做错误捕获处理吗。。。

[zhangqilin]

Flask 有个 Valid 对象
我之前就是参照这个写了个 DjangoValid
给公司自己的项目用的
万幸很好用

[sichuyoudang312]

@Vegetable 当然不会让它报 500 了

[johnsona]

@Vegetable 假设捕捉到下层一个未知的错误，上层应该怎么处理然后返回给前端

[Vegetable]

@jsisjs20130824 一般我会在最外层做一个捕获所有异常的中间件, 然后向客户端返回{code:500,msg:未知错误},然后日志写入堆栈信息.

[Vegetable]

我觉得测试说的有点道理, 我为了避免这种问题,会直接返回参数异常,最多返回一下哪个字段异常了,不会返回为什么异常了.这样就避免了过于细致的类型判断.不过你引入框架的话,往往能够细致而不失优雅的解决.

[ps1aniuge]

我觉得测试说的对，严谨些，让别人挑不出毛病。

[superrichman]

是你的参数转换的问题，接口健壮性不够强

[hell0v2]

一般业务层做处理，不过接口也要 catch 住吧；反正不管怎么协调，前端输入异常的情况下，要有合理的返回

[forkc]

wtform

[johnsona]

@Vegetable 我猜也是，我用的框架可以把 500 注册下来，然后改写返回格式，状态码之类的。比较好奇是统一 200，然后 json 格式统一，是为了方便前端判断去解决吗？抛开日志不说，肯定会打日志