APIJSON使用场景以及其他说明

声明：接触apijson 时日不多，下面的说明也均来自互联网和自己的理解，如果有不对的欢迎大家指正

---

---

前言

APIJSON作为码云最有价值开源项目项目，本身肯定有可取之处，但是网上对于这个框架褒贬不一，个人认为抛开了使用场景来看待框架其实算是耍流氓，就像原来基于springmvc + mybatis 相关框架对于很多的公司也可以适用一样，当然对于扩展而言，确实是之后的spring boot + cloud 相关微服务 确实更有优势，但是这个也是因人而异因场景而已。这里来说说APIJSON,这里发现一个文章是APIJSON作者 tommylemon 的博客园的博客 感觉写的挺好，地址：https://www.cnblogs.com/tommylemon/p/6573740.html

---

一、APIJSON的定位和使用场景

这个来自作者在文章中的声明：开发APIJSON是为了解决小公司、团队及个人开发者中客户端和服务端的接口、文档和沟通问题，简化开发、提高效率、缩短周期。希望大家不要用大公司的业务去要求APIJSON的功能、性能、安全等，而且个人也能力有限，所以只要方便、够用就好。
一般来说小公司只能开发小型系统，只有大公司才能开发大型系统。APIJSON解决的问题在小公司很容易出现并且容易造成致命的影响（开发周期长、产品上线迟导致资金链断裂而倒闭），但大公司因为资源（人才、资金、管理）充裕可以很好地避免这些问题。APIJSON降低了开发门槛和成本，使得小公司也能快速实现产品、节约资源，提高自己的竞争力。
所以从这里也就可以看出在作者看来，apijson的定位是解决小公司、团队及个人开发者产品快速上线，在这里忽略了后端，只需要后端按照设计要求建立相关对象之后，前端就可以直接通过apijson这里的规范直接调用。

二、APIJSON支持的相关功能

APIJSON目前已实现：

• 大体功能：增删改查、分页查询、统计与验证、注册登录、模糊搜索、结构校验、数据保护、远程函数调用等
• 操作方式：增、删、改、查、调用远程函数 操作对象：单个对象、可关联的多个对象、数组等
• 请求方法：GET,HEAD,POST_GET,POST_HEAD,POST,PUT,DELETE
• 请求结构：{Table:{…}}、{Table0:{…},Table1{…},Table2:{…}…}、{"[]":{Table:{…}}}、{"[]":{Table0:{…},Table1{…},“Array0[]”:{…},…}}等各种组合和嵌套
• 返回结构：对应请求结构的各种JSON结构。

"key[]":{}                                         // 查询数组
"key{}":[]                                         // 匹配选项范围
"key{}":">=2,length(key)<10..."                    // 匹配条件范围
"key()":"function(Type0:value0,Type1:value1...)"   // 远程调用函数
"key@":"key0/key1.../targetKey"                    // 引用赋值
"key$":"SQL搜索表达式"                               // 模糊搜索
"key?":"正则表达式"                                  // 正则匹配
"key+":key指定类型的Object                           // 增加/扩展
"key-":key指定类型的Object                           // 减少/去除 
"name:alias"                                       // 新建别名
"@key":key指定类型的Object                           // 关键词。如返回字段@column、排序@order、自定义关键词@position

具体见文档：

https://github.com/TommyLemon/APIJSON

三、APIJSON的使用，性能，安全

关于使用：

用APIJSON比直接传SQL语句要方便且安全得多。

1. APIJSON支持远程函数调用，这是SQL语句没有的特性。
2. SQL delete忘加where条件引发的数据库被清空事件一直都有，前段时间还有一不小心就删了整个公司的新闻。 而客户端请求APIJSON的方法不是GET或HEAD时，客户端发出的Request必须满足服务端的配置（具体看table目录下的sys_Request.sql，可用MySQLWorkbench查看）。并且都只允许操作某个id对应的table，不会发生忘加条件导致非法DELETE,POST,PUT等请求污染甚至清空数据。
3. 主流的编辑器对SQL语句没有检查，一旦出错，可能不仅仅是不能返回正确结果，还可能破坏数据。 而APIJSON的Request使用JSONRequest封装，里面一般都是由业务model给定键值对。

关于性能：

这里引入作者文章 说的话 JSON数据很轻量对客户端设备的性能影响可以忽略不计，至于web前端我还不够深入所以不好回答。

关于安全：

1. APIJSON会对请求的格式进行校验。
2. APIJSON只有GET,HEAD请求才是明文，其它如POST都是非明文，这个和传统方式是一样的。
3. APIJSON会对非GET、HEAD请求的请求方法、结构、内容进行严格校验。
4. APIJSON对Table默认保护不可访问，需要服务端配置允许的请求与结构才能用指定的请求方法与结构访问。

四、APIJSON需要完善的地方

关于使用的方便程度，定位，性能，安全这里 作者确实说了很多，但是这里需要完善的地方作者也说明了，其实就是细分场景的配置，当然作者写这篇博客的时候已经是2年前了，不知道完善的如何了，所以如果项目中对权限要求比较看重的话，需要慎重考虑一下作者说的这个权限场景的问题；

---

总结

关于apijson 在调用形式上确实和传统的严格意义上的前端和后端不太一样，他弱化了后端，将查询等操作的侧重点放到了前端，确实给人眼前一亮的感觉，而且apijson也获得了码云最有价值开源项目起码证明此项目还得得到很多人的认可的。具体相关还需要在使用中不断摸索。