首页   注册   登录
 TommyLemon 最近的时间轴更新

TommyLemon

V2EX 第 324576 号会员,加入于 2018-06-25 14:33:30 +08:00
今日活跃度排名 8164
TommyLemon 最近回复了
9 小时 44 分钟前
回复了 TommyLemon 创建的主题 开源软件 不用写代码 APIJSON 3.5K Star 超第 2 大 ORM 库 Hibernate
其它评论下周回吧
9 小时 44 分钟前
回复了 TommyLemon 创建的主题 开源软件 不用写代码 APIJSON 3.5K Star 超第 2 大 ORM 库 Hibernate
@clino
说的是最后生态内开源库的链接吧,
排版预览时还是正常的,发出来就没对齐了。

设计规范
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3

如何实现其它语言的 APIJSON ?
https://github.com/TommyLemon/APIJSON/issues/38
@TommyLemon
并不觉得“标题立的太高了”

1. 不用写代码 -- 后端不用写代码
“因为 APIJSON 是自动化的,后端不用写代码,就能自动解析前端传的 JSON 参数...”
标题太长可能显示不下,一大堆新闻资讯(包括开源相关的)的标题不都要精简提炼下?

2. 超 Hibernate -- Star 超 Hibernate
事实依据都放上来了,一开始就是那张 Star 趋势图,还带链接,
再不信的话,APIJSON 项目链接都给了,Hibernate 你也能找到(我发的可能你又不信了),你都看下。

不是符合事实就 “早就铺天盖地的用起来了,根本用不着亲自宣传。”,
而是要有很大的影响力才能达到这个效果,一般开发者是 名企或名人 才行,可惜我都不是,只好自己宣传了。
@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 等一样成为业内普遍认可的方案,所以还需要推广,
不太可能现在就有公司写到招聘广告里,但的确已经有一些公司、团队、个人在用了,我们经常在群里回答问题。
@chocotan 你确定是各方面?再仔细看看 25 楼我的回复,我都说了
"Hibernate 代码质量比 APIJSON 高,这点我是承认的,但 APIJSON 的代码质量我自认为也是超过平均水平的,
不服的话,用阿里的 P3C 规范对比下?"

我在另一个社区还提到
"Hibernate 使用率是远高于 APIJSON 的,毕竟从 07 年开源到现在都快 12 年了,APIJSON 才 2 年多一点。"
oschina。net/news/101787/apijson-3-1-0-released#comments

有句话说得很对,"人们总是只看到他们想看到的东西"
@chinvo
很不一样,Parse 是 SaaS 服务,类似的有 Firebase 以及国内的 LeanCloud 等,
它们主要是把业务放到了前端,后端只手写或者自动生成一些细粒度的 RESTful 接口,
很多需求往往要前端调用多个接口再自己组装并处理数据,
有的还提供自己的类似 SQL 的查询语言,例如 LeanCloud 提供的 CQL,功能限制大,官方文档说了:
与 SQL 的主要差异
不支持在 select 中使用 as 关键字为列增加别名。
update 和 delete 不提供批量更新和删除,只能根据 objectId ( where objectId=xxx )和其他条件来更新或者删除某个文档。
不支持 join,关联查询提供 include、relatedTo 等语法来替代(关系查询)。
仅支持部分 SQL 函数(内置函数)。
不支持 group by、having、max、min、sum、distinct 等分组聚合查询语法。

以上都是 CQL 不支持的,但 APIJSON 全都支持。

另外 SaaS 应用场景基本只适合创业项目,
提供的功能都是受限于 SaaS 服务商( Parse 开源了,定制性要好一些),
有了一定规模就非常有必要把后端推到重来了。
而且又因为绑定了服务商的服务,迁移困难。

APIJSON 完全开放源码,容易定制,还能很好地控制权限。


APIJSON 则是 JSON 转 SQL 的协议,基于 JSON 扩展而来,
开源项目中提供了 Java 的 ORM 实现,
还有其它作者提供了 Node.js, C#, PHP 的实现。

APIJSON 为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全自动化的 API。
能大幅降低开发和沟通成本,简化开发流程,缩短开发周期。
适合中小型前后端分离的项目,尤其是互联网创业项目和企业自用项目。

通过自动化 API,前端可以定制任何数据、任何结构!
大部分 HTTP 请求后端再也不用写接口了,更不用写文档了!
前端再也不用和后端沟通接口或文档问题了!再也不会被文档各种错误坑了!
后端再也不用为了兼容旧接口写新版接口和文档了!再也不会被前端随时随地没完没了地烦了!
@TommyLemon
这里只是一个地方,还有我发的一些博客下,我在 Gitee 开源的项目下,都有很多提到 Swagger 的。
github。com/TommyLemon/APIJSON/issues/27
@TommyLemon 甚至有些和 APIJSON 根本就不是同类的项目,例如 Swagger。
@vinsa
不知道你的维度指的是什么。APIJSON 和 Hibernate 都是 Java 的 ORM 库,拿来对比有什么奇怪的?
而且我发布 APIJSON 后,也有很多网友拿来和其它开源库( Hiberate,GraphQL, JPA 等)对比。
@kran
你说的是前端传 SQL ?

解析 SQL 语法,再校验权限、结构、内容,最后再转回 SQL,
不说性能问题,真要这么好搞业内也应该有不错的开源方案了。

而且 SQL 不能直观地反映返回 JSON 的数据结构,
APIJSON 就能做到看请求知结果,所求即所得。

APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
还有 自动加注释、自动生成封装请求 JSON 的代码,用 SQL 方案实现也很困难,甚至根本不可能准确地实现。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   766 人在线   最高记录 3821   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 12ms · UTC 19:08 · PVG 03:08 · LAX 11:08 · JFK 14:08
♥ Do have faith in what you're doing.
沪ICP备16043287号-1