有没有这样的云服务：我只需定义好 mysql 的字段，就可以根据字段生成 restful api 了，我只需要写个前端 app 就行了？
ericgui · 2018-08-16 12:21:34 +08:00 · 6968 次点击这是一个创建于 2289 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题
哎呀，自己写后端简直太他妈纠结了。
或者有这样的现在的 repo 也行
 |
1
wxkvEX 2018-08-16 12:37:03 +08:00 via iPhone
公司有这种轮子，设计好数据库表直接可生成网页和后端代码，就是啰嗦了一些…
|
 |
2
wangxiaoaer 2018-08-16 12:41:13 +08:00 via Android  1
自动生成不难，难的是如何解决表 模型之间的关联关系。
|
 |
3
lhx2008 2018-08-16 12:41:13 +08:00 via Android
bmob 适合你，不过也只是轮子，非常不安全，玩玩就好
|
 |
4
KuroNekoFan 2018-08-16 12:43:49 +08:00 via iPhone
loopback 了解一下
|
 |
5
lihongjie0209 2018-08-16 12:48:18 +08:00
这么解决事务问题?
|
 |
6
Leammin 2018-08-16 12:52:45 +08:00 via Android
spring data rest 似乎还不错
|
 |
7
beginor 2018-08-16 12:57:21 +08:00
我有一套，完全自主研发，还支持多种数据库 sqlserver，mysql，postgresql 😄
|
 |
8
artandlol 2018-08-16 13:22:40 +08:00
类似 serverless 吗？
现在已有的方案只有程序语言，没有 sql 语言的 V 站网友的玩具 ttps://github.com/metrue/fx 正经的 kubeless fission knative 云服务有 aws lamba，azure function,谷歌，阿里等 玩过 fission： http://blog.51cto.com/13922668/2159680 |
 |
9
qinrui 2018-08-16 13:27:20 +08:00 via iPhone
|
 |
10
RubyJack 2018-08-16 13:31:29 +08:00
rails 脚手架了解一下？
|
 |
11
ala2008 2018-08-16 13:48:25 +08:00
弱弱问一句，业务没有吗？
|
 |
12
passerbytiny 2018-08-16 13:53:07 +08:00
以前碰到过，但是是别人公司内部用的，貌似是基于 Play 框架再开发的。
给了 UML 类图，后端接口就自己全部生成了。 当然，前端被坑惨了。 |
 |
13
inrenping 2018-08-16 13:58:06 +08:00
OData 了解一下
|
 |
14
chinvo 2018-08-16 13:59:42 +08:00
firebase
parse 这些都不需要你定义表结构（当然之后你可以锁定创建 /修改表的权限） |
 |
15
devqin 2018-08-16 14:24:35 +08:00
graphql 就是这样搞的，前后端公用一套 schema 前端只需要自己查询数据就可以了。
|
 |
16
TommyLemon 2018-08-16 14:34:29 +08:00 1
后端可以用 APIJSON，就能实现你的需求。
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。 通过自动化 API，前端可以定制任何数据、任何结构！ 大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！ 前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！ 后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！ 在线解析 自动生成文档，清晰可读永远最新 自动生成请求代码，支持 Android 和 iOS 自动生成 JavaBean 文件，一键下载 自动管理与测试接口用例，一键共享 自动校验与格式化 JSON，支持高亮和收展 对于前端 不用再向后端催接口、求文档 数据和结构完全定制，要啥有啥 看请求知结果，所求即所得 可一次获取任何数据、任何结构 能去除重复数据，节省流量提高速度 对于后端 提供通用接口，大部分 API 不用再写 自动生成文档，不用再编写和维护 自动校验权限、自动管理版本、自动防 SQL 注入 开放 API 无需划分版本，始终保持兼容 支持增删改查、模糊搜索、正则匹配、远程函数等 后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！ 创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^ github.com/TommyLemon/APIJSON |
|
17
TommyLemon 2018-08-16 14:38:14 +08:00
@devqin
GraphQL 只是个聚合接口的代理层， 还是得自己去写操作数据库 CRUD 的代码， 要么写 SQL 语句，要么写 ORM 库的调用代码。 APIJSON 远比 GraphQL 强大易用很多 https://juejin.im/post/5ae80edd51882567277433cf |
|
18
TommyLemon 2018-08-16 14:40:35 +08:00
@wangxiaoaer
用 APIJSON，自动化关联查询，还支持自动化的 JOIN(LEFT, RIGHT, INNER 等) https://my.oschina.net/tommylemon/blog/1574430 |
|
19
wangxiaoaer 2018-08-16 14:59:29 +08:00
@passerbytiny #12 前端为啥被坑惨了？
|
 |
20
34C 2018-08-16 15:07:42 +08:00
这么多层楼都没人提到 leancloud.cn 吗…
|
|
21
wangxiaoaer 2018-08-16 15:10:34 +08:00
@TommyLemon #18 说实在的，我没看明白你这个项目干啥用的。
|
 |
22
talisk 2018-08-16 15:10:35 +08:00
同推荐 LeanCloud
|
 |
23
suantong 2018-08-16 15:13:43 +08:00 via Android
自己部署 parse server
|
|
24
TommyLemon 2018-08-16 15:16:45 +08:00
@wangxiaoaer
后端：零用时开发接口、零沟通零被打扰。 前端 /客户端：内容可任意组合、结构可任意嵌套、零沟通零打扰零等待。 后端不用写接口、也不用写文档就能提供"接口"和"文档"，前端 /客户端不用看"文档"就能调用"接口"。 APIJSON 实现了前端 /客户端要什么就返回什么，而不是后端给什么才能用什么，从根本上解决了： 1.浪费性能、流量和带宽 传统 RESTful：返回不需要的字段、对象等 APIJSON：完全由请求指定返回内容，没有不需要的 2.各种奇葩的缩写、混乱的命名 传统 RESTful：各种缩写、拼音、驼峰和非驼峰混用等，只有看文档才知道是什么、才知道用哪个，而且文档还很可能有错误。 例如 评论数量可能是 commentCount, comment_count, cmt_count, pl_num... 分页页码可能是 page, pageNum, page_number, page_num, pnum... APIJSON：常用的字段都已标准化，限制列表数量都用 count，分页页码都用 page，总数都用 total 3.几百甚至上千个混乱的状态码 传统 RESTful：各项目几乎完全不通用，不看相关的内部文档根本不知道对应的错误是什么，而且文档还很可能有错误。 例如 注册: 成功 600, 手机号不合法 601, 验证码错误 603, 手机号已注册 607, 缺少必要字段 609... 评论: 成功 1070, 不允许评论 1071, 参数错误 1073, 动态被删除 1075... APIJSON：只有十几个 HTTP 标准状态码，注释详细，即便不看注释网上一查也有一大堆正确的结果 4.文档过时，与接口不同步 传统 RESTful：后端把接口改了没有及时通知，前端 /客户端莫名其妙调了半天才发现 APIJSON：可以用 APIJSONAuto 在线工具 查看测试用例、以及表和字段的属性，包括名称、类型、长度、默认值、注释等 5.应用界面和接口强耦合难分离 传统 RESTful：比如某个版本的 QQ 空间动态的 JSON 结构必须对应某个版本的某个接口，有时候 JSON 结构甚至是由后端拍脑袋决定的，不好用也得用 APIJSON：完全由请求指定返回的 JSON 结构，即便 UI 变化也不需要对接口做任何更改 6.版本迭代导致大量重复功能的接口 传统 RESTful：为了兼容旧版应用不好直接改原来的接口，一般只能新增 APIJSON：查询不需要对接口做任何更改，增删改可用 WorkBench 等可视化工具 7.前端 /客户端与后端扯皮 传统 RESTful：前端 /客户端想要一次性返回或者更方便解析的结构，但后端想要少写代码 APIJSON：完全由前端 /客户端发的请求指定返回的 JSON 内容与结构，可任意组合任意嵌套，后端完全是自动解析不需要写代码 8.数据库操作不安全 传统 RESTful：delete 忘加 where 直接删光全部数据，只要发生一次 APIJSON：对写操作强制要求指定 id:1(单个)或 id{}:[1,2,3](批量)，并且自动校验权限 9.开发流程繁琐周期长 传统 RESTful：后端写接口>后端写文档>前端 /客户端查文档>(前端 /客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端调用接口>(前端 /客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端解析返回结果>(前端 /客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问) APIJSON：前端 /客户端调用接口>前端 /客户端解析返回结果 为什么要用 APIJSON ？或者 APIJSON 有什么用？ https://github.com/TommyLemon/APIJSON/wiki |
 |
25
CtrlSpace 2018-08-16 15:18:20 +08:00
BaaS
|
 |
26
frantic 2018-08-16 17:23:06 +08:00
我现在在用 LeanCloud 的 BaaS 服务
|
 |
27
reus 2018-08-16 17:23:59 +08:00
毫无意义，只不过是将后端需要实现的逻辑放到前端来实现，工作量一点没少
|
|
28
TommyLemon 2018-08-16 17:52:55 +08:00
|
 |
29
misaka19000 2018-08-16 17:54:55 +08:00
你可以使用 ES，支持通过 HTTP 进行操作，无需定义字段类型
|
 |
30
night98 2018-08-16 17:55:45 +08:00
这样还得给你加个缓存的策略，然后你还得配置后端生成的 api 的缓存策列，这样搞下来还不如用现有后端解决方案，哈哈。
|
 |
31
shapl 2018-08-16 17:56:51 +08:00
我也强烈有这种需求，，，
写完前端交互，又写后端接口。。。要崩溃。。。 |
|
32
TommyLemon 2018-08-16 18:00:21 +08:00
|
 |
33
agagega 2018-08-16 18:16:35 +08:00 via iPhone
Postgrest
|
 |
34
qf19910623 2018-08-16 18:25:09 +08:00
这种很难实现一些复杂一点的业务，最多只能实现简单的数据展示和编辑
|
 |
35
xiaoyanbot 2018-08-16 18:25:43 +08:00
有的， 之前有个 easy rest
|
|
36
TommyLemon 2018-08-16 18:30:15 +08:00
@qf19910623
主要还是因为 RESTful 的限制，对多表操作的描述不够友好。 APIJSON 就比 RESTful 强大灵活很多，还提供自动化的增删改查 API。 看上面 TommyLemon 的回答。 |
 |
37
Cbdy 2018-08-16 18:42:17 +08:00 via Android
spring data rest 了解一下
|
 |
38
realpg 2018-08-16 19:46:39 +08:00
springmvc 的简单开发，基本就是写配置文件 2333
|
 |
39
ctsed 2018-08-16 19:56:32 +08:00 via Android
@TommyLemon 权限控制怎么搞
|
 |
40
ratazzi 2018-08-16 19:58:11 +08:00 via iPhone
|
 |
41
xud6 2018-08-16 20:13:24 +08:00
firebase https://firebase.google.com/
除了不是 mysql，几乎完全满足你的需求 |
|
42
TommyLemon 2018-08-16 21:58:18 +08:00
@ctsed APIJSON 提供了自动化权限管理，
3 行代码就可配置一张表的增删改查权限， 细分到每张表、每条记录、每个角色、每种操作。 https://my.oschina.net/tommylemon/blog/889074 |
 |
43
zkwap 2018-08-16 22:23:44 +08:00
BaaS 服务吧，这种很多，前端就可以实现大部分功能
|
 |
44
ericgui OP |
|
45
xud6 2018-08-17 10:46:58 +08:00
|
 |
46
jswh 2018-08-17 11:50:35 +08:00
写过，只适合后台系统。客户端系统不合适。
|
|
47
passerbytiny 2018-08-17 12:02:21 +08:00
@wangxiaoaer
前端想要稍微复杂一点的查询，就要自己写 HQL 语句，然而 HQL 语句是纯后端的。 深入一点的说，那个框架只是把领域模型中的实体暴漏成了 RESTFul 资源，整个框架，只处理实体，然而实体并不是后端的全部（虽然它是核心）。贫血领域模型至少还需要 Service 层（处理后端业务）和 Web 层（转换前后端参数）。常规领域模型则需要应用服务（转换前后端参数），领域服务（处理复杂业务），领域事件（解耦）。 说句实话，如果后端只是对数据库的增删改查，还不如不要后端，前端直接操作数据库（最多为了安全添加一个数据库的代理服务器）。 |
|
48
TommyLemon 2018-08-17 14:39:37 +08:00
@passerbytiny
哈哈，HQL 本来就是基于数据库 SQL 的改造语法， 前端写这东西当然头疼了， 既要付出不少的学习成本， 还不够直观，不能直接看出返回的数据结构， 权限控制也很难搞。 APIJSON 基于 JSON，非常直观、易学易用、强大灵活， 自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。 通过自动化 API，前端可以定制任何数据、任何结构！ 大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！ 前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！ 后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！ 在线解析 自动生成文档，清晰可读永远最新 自动生成请求代码，支持 Android 和 iOS 自动生成 JavaBean 文件，一键下载 自动管理与测试接口用例，一键共享 自动校验与格式化 JSON，支持高亮和收展 对于前端 不用再向后端催接口、求文档 数据和结构完全定制，要啥有啥 看请求知结果，所求即所得 可一次获取任何数据、任何结构 能去除重复数据，节省流量提高速度 对于后端 提供通用接口，大部分 API 不用再写 自动生成文档，不用再编写和维护 自动校验权限、自动管理版本、自动防 SQL 注入 开放 API 无需划分版本，始终保持兼容 支持增删改查、模糊搜索、正则匹配、远程函数等 后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！ 创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^ github.com/TommyLemon/APIJSON |
|
49
ericgui OP @TommyLemon 老铁，你这个示例代码，是这样的 URL： http://apijson.org:8080/get
说好的 RESTful API 呢？不是 URL 里面不用 HTTP 方法的动词么？ 恕我经验浅薄，看不懂这个 URL |
|
50
TommyLemon 2018-08-18 10:48:23 +08:00
@ericgui
确实不是 RESTful，但你一定要 RESTful 么？ 不就是想更快地实现 HTTP API 嘛。 人们总说自己想要更快的马，其实他们想要的是汽车。 生成 RESTful API 的库有很多，生成的都是对单表的简单增删改查 API， 只能满足特定的需求，没有一个能真正做到实现复杂需求， 也没有一个能做到生成后大部分都不需要改就能实现你自己的业务需求， 而且权限控制也得自己做。 APIJSON 根本不会生成任何 API， 而是自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。 前端改了参数，后端生成的 SQL 语句也会跟着改变， 并且用完后不会保存，因为保存就意味着要维护。 APIJSON 能轻松地定制任何数据、任何结构，还不需要后端写 API 就能实现。 可以在线体验 http://apijson.org/ 或者看视频教程 http://i.youku.com/apijson |
Select Language