前言

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语句要方便且安全得多。

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

关于性能：

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

关于安全：

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

四、APIJSON需要完善的地方

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

总结

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

APIJSON使用场景以及其他说明相关推荐

Tencent APIJSON-自动化接口和文档 ORM 库开源啦
APIJSON是一种专为API而生的JSON网络传输协议以及基于这套协议实现的ORM库. 为简单的增删改查.复杂的查询.简单的事务操作提供了完全自动化的API. 能大幅降低开发和沟通成本,简化开发流程 ...
Q102：光线追踪场景（5）——驭龙台
0,引入 "驭龙台"这个名字是后来起的,原本只是打算设计这么一个场景,如下图: 先申明一点:"驭龙台"场景中的大部分图形都是有磨边的楔形构成. 对于场景中的台阶 ...
Q102：光线追踪场景（4）——面朝大海
0,引入想象这么一个场景: 海边有一个古老的凉亭.雕刻着古时壁画的屋檐:砂岩的地板:亭内摆放着一个木质的茶桌:茶桌上摆着大理石的茶杯和茶壶:紧挨着茶桌有一个圆形的坐垫:小白兔和小灰兔静静地蹲坐在地板 ...
Q102：光线追踪场景（3）——Two Horses
0,引入这个场景中包含两匹马,不知道怎么起名,所以就叫"Two Horses"啦.还有就是用到各种反射模型.各种光照模型.各种纹理.PLY格式的几何模型. 贴图如下: 1,测试代 ...
Q102：光线追踪场景（2）——PLYs（多种模型汇集）
0,引入这一章节里,trace的图形包含多种PLY文件表示的图形. 比如:bunny.dragon.hand skeleton.horse等. 主要涉及两件事情: 1,将这些模型添加到场景中: 2, ...
Q102：光线追踪场景（1）——地球仪
0,引入这一章节里,咱们trace这样一个包含地球仪的场景,直接贴出结果图形啦! 这个场景中包含如下几部分: 1,地球仪的底座(1个回旋面+1个圆柱面,Phong材质,木纹纹理): 2,地球仪的主体 ...
短地址短链接免费接口：缩短链接地址。可用于缩短链接场景，如：电子发票链接，促销活动链接，新闻文章链接等
短地址短链接接口服务,申请后即可免费使用,提供全接口服务,缩短链接地址,广泛应用于缩短链接场景,如:电子发票链接,促销活动链接,新闻文章链接等. 使用说明: 1.以下短地址接口开发资料供开发技术人员参 ...
腾讯业务百万数据 6s 响应，APIJSON 性能优化背后的故事
最近发生了一件大事儿,APIJSON 再也不用担心被人质疑性能问题了哈哈! 某周三腾讯 CSIG 某项目组(已经用 APIJSON 做完一期)突然反馈了查询大量数据性能急剧下降的情况: 某张表 2.3 ...
Tencent APIJSON 零代码、全功能、强安全 ORM 库后端接口和文档零代码，前端(客户端) 定制返回 JSON 的数据和结构
项目介绍零代码.全功能.强安全 ORM 库后端接口和文档零代码,前端(客户端) 定制返回 JSON 的数据和结构. A JSON Transmission Protocol and an ORM ...

APIJSON使用场景以及其他说明

文章目录

前言