封装方法，为空不拼接，或者拼接空字符串。
不过你也可以试试 APIJSON， key: value 中 value 为空是不会拼接 SQL 的。

🚀后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
https://github.com/TommyLemon/APIJSON

造轮子，例如这个 Android 快速开发框架，2.9K Star
github.com/TommyLemon/Android-ZBLibrary

也保留两位小数

@MuscleOf2016 机器学习代码用 js 写的，然后 java （用的是 SpringBoot 框架） 调用。
现在有个问题，IDE 调试还是正常的，打包成 jar 后，java 读取不到 js 文件
https://www.oschina.net/question/3739440_2273949

试过 getInputStream，pom 配置 resource 等 10 多种组合方式都不行，
大家有什么解决方法吗？

@MuscleOf2016 部分正确。
它是调用接口拿到真实的结果，然后和最近的正确的真实结果来对比。

不过 机器学习测试 和 普通测试 有点不一样，它会对正确结果抽取一个模型，里面描述了 类型、值的范围、长度范围 等属性，
不论是
有问题的 值 所在路径（例如 list/0/User/name, User/contactIdList/1 ），
还是对比结论（状态码改变、缺少字段、新增字段、值超出范围、值类型改变）
都更精准，容错性也更好。
而且每次纠错后都会学习新的正确结果，然后更新原来的标准，数据越多模型越理想。

猝死的前兆啊，命要紧，赶紧休息，还管那么多。。。

@connection 对的，自动请求所有接口，然后自动对比每个接口返回的结果，不需要写任何代码

@lusheldon 这位兄弟 @mikuazusa 理解到位，APIJSONAuto 是用结果来对比的，不用管过程怎么样。
而且预设结果只需要点一下回归测试按钮，然后点击 [这是对的] 按钮，就生成 /更新 了对比标准。
也不需要像其他工具一样要写代码来断言。
可以试试
http://apijson.org/

@lusheldon 有的，但不是查数据库，而是自动根据上一次的正确结果来对比。
数据准备 不需要写任何代码，不需要 Mock，直接通过你上传的接口来获取。
数据清理 不属于接口工具的功能，这是你们自己的业务，可以写脚本或用专门的工具。

这是用 APIJSONAuto （前端） 和 APIJSON （后端） 做的接口管理平台，
额外提供机器学习测试，目前线上环境还有 bug 暂时不能用这个功能，可以用接口托管等其它所有功能。
apijson.org

@MuscleOf2016 开发

@TommyLemon
这个是我写的开源库，创作不易，GitHub 右上角点 Star 支持下吧，谢谢 ^_^
https://github.com/TommyLemon/APIJSONAuto

测试接口用的是 APIJSONAuto，原来是测试那边写 Python 脚本，现在都不用了。
自动生成接口文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动给请求 JSON 加注释，一键切换
自动保存历史请求记录，一键恢复
自动校验与格式化 JSON，支持高亮和收展

缺点是部分情况下需要手动纠错。

http://i.youku.com/apijson

@TommyLemon 有些 SDK 抛的异常，有必要替换成你自己的，
例如
NoSuchMethodException("... did not find method getOrder, ..."),
DuplicatedEntryException("... phone is a unique column and 12345 already exist ...")，
可以换成自己封装的
ServerException("服务器内部错误") ，
ConflictException("手机号已注册")
等，
一方面可以更简单明确地告诉调用方出了什么问题，
另一方面可以避免信息泄露（ SQLSyntaxError 里面可能会有 SQL 片段，暴露出 表名、字段名等）

必要的地方一定要用，尤其是涉及业务处理的地方，
例如 手机号已注册异常、订单已完成 /取消不允许改商品 /付款 等。

先 try-catch，然后 catch 内判断判断环境，
开发环境下重新 throw 出来，尽早暴露 bug 尽早解决，fail fast ；
线上环境就写日志，以便追踪错误。

在返回给 HTTP API 调用方（一般是写在 Controller 里面）前，
把 Exception 转成 错误码 status 和 错误信息 message，
毕竟人家可不想看到一堆后端的堆栈信息，而且没有 status 也不好处理。

还有线上环境千万不能因为部分接口异常导致整个服务挂掉，
虽然 SpringBoot 等框架会统一 catch 避免这种问题，
并在 Response Header 返回 status 和 message，
但还是自己 catch 到封装成业务状态码和错误信息更好，
尤其是在 业务错误码 和 HTTP status 有重合的情况下会不好区分，
HTTP status 更多地是用在连接状态上，
自定义的 status 是用于自己的业务处理状态。

面试时看招聘要求，人家要啥你就得会啥；
工作时在满足需求的前提下尽可能用简单的方案。

SpringBoot 能火起来就是因为简单易用，省去了大量 XML 配置。
APIJSON 基于 SpringBoot，从 路由 到 数据库 CRUD 的代码全都省掉了，
后端不用写代码就能提供接口给前端灵活调用了，可以查任何数据和结构
github。com/TommyLemon/APIJSON