ApiAuto接口管理

（一）官方介绍

敏捷开发最强大易用的 HTTP 接口工具，机器学习零代码测试、生成代码与静态检查、生成文档与光标悬浮注释

行业类似的产品有 Postman, Swagger, YApi, Rap等等，是一款接口测试工具

支持 HTTP GET/POST API，智能显示和切换；支持一键导入 Swagger, Rap, YApi 的用例和文档。

（二）APIAuto功能介绍

测试地址：http://apijson.org/api/

（1）安装使用

可以直接下载源码解压后用浏览器打开 index.html，建议用 Chrome 或火狐 (Safari、Edge、IE 等可能有兼容问题)。
也可以直接访问官网的线上环境 http://apijson.cn/api 或开发环境 http://apijson.org:8000/api 。

把左侧 URL 输入框内基地址改为你主机的地址(例如 http://localhost:8080 )，
然后在右上角设置下拉菜单内修改数据库类型Database、数据库模式Schema

参考如下：
在这里插入图片描述

（2）测试ApiJson项目

在这里插入图片描述
1：可以通过APIAuto测试ApiJson项目，并且在我们键入操作语句时该平台会自动的给出语法提示和错误提示
2：APIAuto支持随机参数，可以指定请求HTTP体某个参数的值，可以设置随机范围，数据类型，顺序参数，测试次数等等，这些对于接口测试还是非常实用的，这些功能在YAPI和MeterSphere也有体现

（3）实时快捷查询文档

在这里插入图片描述
APIAuto不需要特定的接口文档，它的文档时相对于数据库的注释信息的，可以在该平台实时查看数据文档（即接口文档）

（4）基本功能概览

在这里插入图片描述

ApiJson和ApiAuto总结

备注：本次主要介绍了三个平台:ApiJson、ApiAuto、UnitAuto。其中ApiJson和ApiAuto属于搭配使用到的，ApiAuto是测试ApiJson操作的接口平台，而UnitAuto不仅仅可以测试ApiJson，它可以测试其他的项目，跟它们没有特别的关联，属于ApiAuto设计理念的发散扩展

传统方式	APIJSON	简单分析
各种奇葩的缩写、混乱的命名	常用的字段都已标准化	ApiJson构建了自己的一套规则体系，默认设置了开发标准
文档过时，与接口不同步	自动实时生成正确的文档	文档表示的数据库文档，不是一般意义的接口文档，是给前端人员看的
数据类型不稳定或随意改变	自动化API保证类型稳定	都是统一的JSON数据
几百甚至上千个混乱的状态码	十几个HTTP标准状态码	状态码由ApiJson提供这也就避免了不同人员设置不同的状态码
前端/客户端与后端扯皮	后端不写代码，前端直接调用	后端需要完成基础的配置，只需要很少量的代码即可，任务转发给前端
开发流程繁琐周期长	大幅精简开发流程	1：具体的开发流程需要具体到不同公司的开发体系 2：相对于传统方式确实提高了效率

优势

【1】ApiAuto智能显示和切换是非常友好的设计，这能够帮助我们减少错误，可以在测试之前就发现问题
【2】ApiJson开发如果前端积累了一定的经验并且做好了各个代码组件的封装，那么整体的开发是非常快速遍历的，很适合小型项目自用项目的落地
【3】ApiJson的查询方式与ES的DSL语句使用方式类似，如果熟悉DSL查询的话，那么在应用实践上的切换是比较容易的
在这里插入图片描述
【4】现对于传统的开发方式，ApiJson确实在一定程度上提高了效率，这主要从以下几点体现。第一：前端不依赖于后端的接口文档，在ApiAuto上自己根据实时文档进行自定义选择，这就避免了人员间的沟通和前后端开发等待交互滞后的问题。第二：目前看来ApiJson的使用还是比较简单的，但是在前端代码上由于还未成熟代码风格不好，这个会存在一些问题。但是只要这个稳定发展相关的前端代码重用组件不断扩展，那么前端在组合各种操作上也会更加便捷和方便

【5】就目前实践经验而言，ApiJson对于一般的增删改查是没有问题的，而且操作起来也很便利。此外，对于使用JSON这种结构查询方式而言，它所提供的查询方式在后期也会更加的强大，复杂的查询也基本都能够实现，并且有ES这种结构化查询作为类似参考，可以看出ApiJson的对于复杂查询在未来也是不会有问题的

【6】执行效率上，后端主要负责的就是JSON的解析，而这也是ApiJson的核心所在，查询效率上由于目前测试数据量较小而且他的适用范围也偏向于中小项目，这个并未进行具体的落地测试（只要后端ORM库在解析JSON时不会太慢就行）

劣势

【1】虽然后端不需要写过多的代码了，但是ApiJson自己也设置了很多的步骤，比如注册映射，注册权限，request表配置等等，这些都是需要额外的去处理的

【2】ApiJson自己提供了一些安全权限的设置，但是这个目前为止感觉不适合通用项目，对于自用项目的话，还是需要自己单独写认证相关代码

【3】后端的任务减轻，但是这也意味着前端的任务量增加。此外，对于前端而言，增加的不仅仅是任务量，还有原来后端的任务和责任与之相关的所有责任，因为后端不需要做任何操作，所有的数据都是前端自己决定和选择，这对于前端的要求更加严格。

【4】前端在一定程度上与数据库的过多依赖耦合，而这在某些时候必然会造成问题。如果数据库结构发生变化，是否也意味着前端对应的所有请求JSON需要调整。否则将发生异常。而这样的问题，在某些层面不满足软件设计的原则，数据、视图、模型的分离和解耦。

【5】安全性问题，前端通过这样的方式相当于拿到了数据库的访问秘钥。那么如果有人清楚这样的开发模型并且拿到了相关的权限秘钥就可以按照POST/PUT/DELETE任意操作数据库，由于APIJSON使用的都是通用的开发模型，那么只要根据前端请求JSON就可以清楚的知道数据库的表名、字段，如果知道了表名那么只要一个简单的GET请求就可以获取到数据库的所有字段以及所有数据，这个安全风险需要重视。备注：虽然APIJSON已经给我们提供了隐藏表名的设置，但是第三方用户只不过不知道实际的表名但是数据和字段其实是一样可以拿到的

【6】工程化考虑，使用APIJSON意味着我们要将这部分的代码完全交给APIJSON来管理，这对于中大型的项目工程或者业务较复杂的工程，不是很适合。尤其对于需要依赖较多的中间件、服务调用、复杂业务处理、核心业务处理不是很适合

【7】代码实践考虑，目前来看虽然可以满足基本的开发，但是很是有较多的问题，官方并未帮助我们封装好各个组件，这个就需要自己去构建。此外，对于ApiJson和ApiAuto在使用中发现问题较多，很多问题不清楚是Bug还是实践方式问题，官方文档以及相关资料虽然很多但是很杂，缺少真正帮助项目落地的参考实践，这个就需要自己不断实践不断总结了