如何更好的处理用户上传的JSON数据?

用户上传JSON数据到我们服务端,我们需要进行解析处理,之后我们再上传到云端。现在我们这边有两种意见:

第一种就是在服务端进行JSON格式校验,包括解析后需要上传到云端的数据都需要进行校验后才上传。因为JSON嵌套的层次较深,我们每解析一层都需要判断是否为空。只要出现为空就直接进行错误处理。

第二种则是假定用户上传的数据都是合法的,只要在最外层捕获一个异常,保证该线程不会挂,里面解析和处理都不用做任何判断和校验。两种各有利弊,请问下这种情况,一般该如何处理?

回复内容:

用户上传JSON数据到我们服务端,我们需要进行解析处理,之后我们再上传到云端。现在我们这边有两种意见:

第一种就是在服务端进行JSON格式校验,包括解析后需要上传到云端的数据都需要进行校验后才上传。因为JSON嵌套的层次较深,我们每解析一层都需要判断是否为空。只要出现为空就直接进行错误处理。

第二种则是假定用户上传的数据都是合法的,只要在最外层捕获一个异常,保证该线程不会挂,里面解析和处理都不用做任何判断和校验。两种各有利弊,请问下这种情况,一般该如何处理?

不正确的数据必须挡在第一道大门之外

首先不能假定处理失败(抛出异常) == 数据有错误。这两点肯定没有必然的联系。总会有数据业务逻辑上必须,但不填却不会引发程序的致命错误。

当然也可以说把数据的校验,跟随着事务处理的过程逐步进行。但这会导致两个问题:

  1. 时间的拖延,不能立刻得到数据合法与否的反馈结果;用户总是会用各种想不到的办法试验API,他们希望犯错时得到立刻的反馈,而不是等服务器处理半天失败了才知道。
  2. 执行了一半的事务还要特意丢弃,浪费服务器处理资源,绝对不如对非法数据干脆就不开启事务。

请坚持得到用户数据输入时第一时间进行校验。对于RESTful风格API而言,你可以考虑返回对应的HTTP错误状态码以及JSON格式的错误信息正文,帮助用户得到正确的反馈。


题外话。

对于API接口还差一点儿。但对网页表单接口来说,在这个目的上Node.js就会体现出绝大的优势:对于Node.js程序来说,前端和后端的数据校验代码是直接复用的!

如果对于一般的PHP后端来说,可能就要想点办法了。我建议可以自己规定一套统一的JSON格式校验表,定义哪些数据字段需要哪些约束条件(required、email、number等),然后前后段查同一张校验表,去写通用的代码做校验。

比较忌讳的是同一个目的的校验代码,手工用原生的JS和PHP写两份——维护两份同样目的代码的同步,做过就知道会死人了!

看你们对出现为空的数据的定义是什么:如果正确的数据允许出现空,就要进行空判断和错误处理;如果出现空肯定是错误的数据,那么在外层捕捉异常即可。

1、上传之前判断关键数据是否为空
2、上传到服务端全部验证
3、展示或用的时候,要处理异常

  1. 异常和线程挂掉有必然联系吗?数据异常校验导致线程挂掉,只能说是程序的异常处理机制没做好。很多人都喜欢捕捉到异常后直接抛出堆栈信息,而不是对异常进行处理,每次见到这种处理,我都会抓狂。抛出了,还得去分析抛出原因,甚至是分许需求,坑人呢。例如:if(){....},这样就结束了。我靠。else呢,就算你不记录日志,或者其他处理,至少也得打印一下,让人一调试就知道,哦。问题出现在这里了。而不是靠IDE的debug一步步去跟进。(题外话,啰嗦了。)。。。相信lz只要出现为空就直接进行错误处理,所谓的处理就是直接把线程干掉。。。囧。。。

  2. 至于第二点,我不知道lz是基于客户的善良,还是基于客户就是自己,居然假设“用户上传的数据都是合法的”,对于编程人员,这种假设是最致命的,无论是从设计还是编码,因为你根本就无法完全代表得了客户的所有操作,其实这也证明了上面的看法,lz的程序对于异常处理不够健壮。可能编写的时候,就只考虑了正常输入状态,而没有考虑非正常输入状态。所以在设计或者编码时,最好不要假设客户怎样怎样。如果真的假设了,请拿出能支撑着假设的数据。上面的,你假设上传的数据是合法的,你自己问一下,如果说服老板或者客户你的这个假设是成立的(请客户保证每次输入都是合法的?)你的假设应该是这样的:上传时程序已经对数据经过了严密的验证,数据基本保证符合格式(对不起,意外永远都会出现),后面的程序获取的数据都是合法的。如何证明后面的程序获取数据是合法的,把验证的程序拿出来,这就是证明的。当然,验证程序不够严谨,或者有些没有加入验证程序,这是另外一方面的。毕竟也有人会追问:你如何证明你的验证程序的准确率,有没有验证。。

  3. 最后一点,从安全性来说,数据至少是得经过验证的。经过验证的数据,至少能过滤掉已知的潜在危险。

  4. 对于lz的问题,除非是用户上传的数据不重要,不然都是要经过数据验证的.