@
sagaxu 我说的是不改后端代码，这是前端发的 JSON 参数。
===============================================
1.用什么方式都能做，前提都是后端服务支持，只是传统方式要后端写代码支持，而 APIJSON 几乎没有成本，尤其是对于后端开发来说。
2.APIJSON 规范了：
页码(统一用 page 代替 pageNum, page_index, pnum 等),
每页数量(统一用 count 代替 pageSize, pcount 等 ),
搜索关键词（统一用 $, ~ 代替原来的 serach，searchKey, s, query, q 等）,
连续范围 Between and(统一用 % 代替原来的 start=1&end=2, s=1&e=2, from=1&to=2 等)
包含值(统一用 <> 代替原来的 contains, con, cts, include, ild, inc 等)
增加或扩展 (统一用 + 代替原来的 add, plus, pls, append, appd, appe 等)
减少或去除 (统一用 - 代替原来的 remove, reduce, delete, rmv, red, del 等)
比较运算 (统一用 > 代替原来的 gt, <= 代替原来的 lte，id != 1 代替原来的 "id": { "ne": 1 } 等 各种不直观的写法)
逻辑运算 (统一用 & 代替原来的 and, |(可省略) 代替原来的 or， ! 代替原来的 not 等 各种不直观的写法)
...
传统方式开发的接口，不同的人对以上的命名很可能不一样，甚至同一个人写的不同接口都有可能不一样，
前端需要针对每个接口去查看文档或找后端确定，如果复制另一个相似接口的调用代码，
而不改名称（以为搜索 key 都是 seachKey ），接口调不通最后确定是这种问题，不是很恼火？
APIJSON 对以上功能是强制这样写关键词 /符号的，不是的话，调自动化 APIJSON 是得不到正确结果的，
还可能返回具体的错误信息，例如
"GET 请求，字符 id= 不合法！ key:value 中的 key 只能关键词 '@key' 或 'key[逻辑符][条件符]' 或 PUT 请求下的 'key+' / 'key-' ！"
"id{}:range 类型为 Integer ！ range 只能是 用','分隔条件的字符串 或者 可取选项 JSONArray ！"
当然其它一些命名，例如字段名等不能抽象的东西确实是没法强制了，强制的话会导致满足不了业务需求。
3.你说的很对，但现实就有大量 PHP 等动态类型语言写的后端啊，我是见过空对象变成 [] 返回导致线上 App 挂掉的。
难道就视而不见，或者强制使用 Java，Go 等静态类型语言？谁有这个权利，还能承担这个风险？
而且即便是静态类型语言，也有部分后端开发者不遵守约定改掉类型的，开发与测试环境常见，
可能是原来的类型不满足需求，或者有代码洁癖，看不惯以前不一致的代码自己重构了，前端必须改代码来兼容。
用 APIJSON 低成本、低风险地简单解决不好吗？而且还是从源头上避免问题的发生。
4.不能，但问题是 APIJSON 起码能保证 自动化 API 是返回标准且统一的 状态码的，传统方式啥都保证不了，全靠人。
人都是懒的，能用自动化 API 简单解决的，他就不大可能会自己写，又因为大部分 CRUD 是能用自动化 API 做，
所以大部分 CRUD API 就能保证状态码标准和统一了。
至于调第三方的接口，如果是前端直接调用，则前端特殊处理；如果是后端调用，一般都是手动写的接口，
不管是前端特殊处理，还是后端转成标准的状态码，都是可行的。
5.业务逻辑、流程图又不是后端给前端的，这是产品需求给的。后端只是提供 API，告诉前端怎么调用。
至于 UML 图，基本只是后端用来描述表关系，内部交接的时候用下，前端不需要关心。
6.非常多，非常普遍，可能你所在的项目组是严格按照前后端约定好文档再开发接口，很好地落实了这个流程，
但大部分中小型企业，还真的比较少有 合理的组织、规范的流程、良好的落实、高素质的开发团队。
能用 APIJSON 低成本解决的问题，就不要用 高成本的管理 来死磕了嘛。
APIJSON 的规范统一的，你换项目、换公司还是一样，Learn once, write anywhere.
用传统方式，别说换公司、换项目、就是换个后端开发甚至只是换个接口，就很可能不一样了，得一遍遍学习和适应。
你觉得不是问题的问题，可能是你没注意到，或者你经历过的项目确实不存在，但不代表一大堆中小型企业啊。
如果都和你是一样的看法，怎么会有这么多人支持我呢？或许你的项目环境比较优越，以至于 “何不食肉糜？”
===============================================
一个项目从开源到普及是需要时间的，APIJSON 效果确实好，但还有大量业务的开发人员、企业都不知道不了解，
而且 APIJSON 确实也没有火到像 SpringBoot，Mybatis，Redis 等一样成为业内普遍认可的方案，所以还需要推广，
不太可能现在就有公司写到招聘广告里，但的确已经有一些公司、团队、个人在用了，我们经常在群里回答问题。