表单验证

Question

对于一次性提交多个字段信息的表单验证，很多验证操作前端校验有很多的局限性，鉴于好的接口应当避免被滥用的api设计原则，我的想法是后端做好严格的限制，阻止各种预料之外的接口调用情况发生。而这种验证就是返回通常不止一条错误，drf的形式是[{‘field1’:‘error1’, ‘field2’:‘error2’, ‘non_field_error’:‘error’}]。前端同事在这里跟我有分歧了，我的想法是像这种能对应到具体错误的field error应该显示到相应的填写框下面，对于比如联合唯一错误的non_field_error的错误应当显示到表单的最上面或者最下面。
首先，请问老师这种做法是不是一种通用做法？有没有什么更好的办法？
第二：这个前端实现起来性能开销大吗，实现难度高吗？
这个问题我跟前端同事有分歧好久了，我就是觉得他们做的前端页面不能更加人性化的显示错误。

Answer 1

bobby 2020-08-05 11:31:50

1. 这种做法就是drf的默认做法，挺合理的，前端分歧那么前端的说法是什么？为什么不同意呢，只要大家说的有理就行
   

2. 前端实现起来难度也不大啊，因为很多框架都会配备验证库的，比如elementui就有，前端只需要配置就行了

3. 从合理性上来讲，前端和后端都应该做验证的，那么为什么呢？ 1. 前端不论做不做后端都得做，这是安全考虑，那为什么后端做了前端也应该做呢？：1. 用户体验好 2. 如果假设用户提交的表单可能70%都有错误，这种错误前端如果能检查出来，那么就不用提交到后端验证，这样就给后端减轻了70%的请求处理压力了。所以为了性能考虑前端做也是合理的
   

• 提问者 改变自己c #1

  前端同学的回答是实现起来比较复杂麻烦。我感觉不应该很麻烦啊。他们的说法是后端还会raise Value('xxxx')这种错误，没有对应的key，前端拿到不好处理，或者说情况比较多不好处理。

• bobby 回复 提问者 改变自己c #2

  如果这样 那么最好是大家一起商量一种好的方式，你可以要求对方能应对未来可能出现的情况，以及如果你觉得对方不好确定，那么你找对方当前前端负责人一起商量一下，既然指定了规则那么就要考虑到：1. 是否这个规则能尽量覆盖全面的情况 比如有些情况可能考虑不到导致后期双方改动都大 2. 后期这种规范是否会带来各种额外的开发负担
  还有最后 一个建议就是 graphql，这种模式前端会比较喜欢 你也可以调研一下这个技术