GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||
GeezerVison is showing github.com — Home Home
TommyLemon edited this page
接口全万能,前端不求人。要啥就有啥,所求即所得。 后端:零用时开发接口、零沟通零被打扰。 后端不用写接口、也不用写文档就能提供"接口"和"文档",前端(客户端)不用看"文档"就能调用"接口"。 APIJSON 实现了前端(客户端)要什么就返回什么,而不是后端给什么才能用什么, 传统方式:后端写接口>后端写文档>前端/客户端查文档>(前端(客户端)关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端(客户端)调用接口>(前端(客户端)关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端(客户端)解析返回结果>(前端(客户端)关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问) APIJSON:前端(客户端)调用接口>前端(客户端)解析返回结果 传统方式:前端(客户端)想要一次性返回或者更方便解析的结构,但后端想要少写代码 传统方式:对象为空时应该返回 null 或 {} ,但实际会返回空数组 [] (常见于 PHP, Lua 等脚本语言开发的后端 HTTP API), 传统方式:后端把接口改了没有及时通知,前端(客户端)莫名其妙调了半天才发现 传统方式:DELETE 忘加 WHERE 直接删光全部数据,只要发生一次 传统方式:各项目几乎完全不通用,不看相关的内部文档根本不知道对应的错误是什么,而且文档还很可能有错误。 传统方式:各种缩写、拼音、驼峰和非驼峰混用等, 传统方式:比如某个版本的 QQ 空间动态的 JSON 结构必须对应某个版本的某个接口, 传统方式:为了兼容旧版应用不好直接改原来的接口,一般只能新增 传统方式:返回不需要的字段、对象等 ... 其它所有的接口开发库、框架、生成代码工具等, 考虑实际情况下不仅要操作数据库,还要校验接口参数和用户权限等,以及需求不会覆盖排列组合嵌套的所有可能, 按照一般互联网中小型项目情况可得出以下对比表格:
APIJSONORM 将 APIJSON 格式的请求 JSON 自动转换为 SQL 语句连接数据库并执行, 内置角色见 AbstractVerifier.java 的角色常量。
还可自动校验内容,比如在数据库配置 "VERIFY":{ "type{}":[0,1,2] } 就能校验 type 的值是不是 0,1,2 中的一个。 "VERIFY": { "money&{}":">0,<=10000", "key-()":"verifyAccess()" } // 自动验证是否 money>0 & money<=10000,通过远程函数自定义验证权限 "TYPE": { "balance": "DECIMAL" } // 自动验证 balance 类型是否为 BigDecimal "UNIQUE": "phone" // 强制 phone 的值为数据库中没有的 "MUST": "id,name" // 强制传 id,name 两个字段 "REFUSE": "balance" // 禁止传 balance 字段 "INSERT": { "@role": "OWNER" } // 如果没传 @role 就自动添加 "UPDATE": { "id@": "User/id" } // 强制放入键值对 全部操作符见 Operation.java 的注释
大体功能: 操作方式: 操作对象: 请求方法: 请求结构: 返回结构: 功能符号: "key[]":{} // 查询数组 "key{}":[1,2,3] // 匹配选项范围 "key{}":"<=10;length(key)>1..." // 匹配条件范围 "key()":"function(arg0,arg1...)" // 远程调用函数 "key@":"key0/key1.../targetKey" // 引用赋值 "key$":"%abc%" // 模糊搜索 "key~":"^[0-9]+$" // 正则匹配 "key%":"2018-01-01,2018-10-01" // 连续范围 "key+":[1] // 增加/扩展 "key-":888.88 // 减少/去除 "name:alias" // 新建别名 "@combine":"name~,tag~" // 条件组合 "@column":"id,sex,name" // 返回字段 "@group":"userId" // 分组方式 "@having":"max(id)>=100" // 聚合函数 "@order":"date-,name+" // 排序方式 "@schema":"sys" // 集合空间 "@database":"POSTGRESQL" // 跨数据库 "@datasource":"DRUID" // 多数据源 "@explain":true // 性能分析 "@role":"LOGIN" // 访问角色 详细说明见通用文档中的 功能符
创作不易、坚持更难,右上角点 ⭐Star 支持下吧,谢谢 ^_^ Clone this wiki locally | ||||||||||||||||||||||||||||||
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |