一个后端服务只向外提供一个借口,全用 post ,通过定义不同的业务 code 进行处理,我之前有个小系统就这样搞过,并且我还觉得前端反而会不会简单些,只用一个接口,而有的项目用 rest 风格,有的反而有点不伦不类,大佬些觉得如何呢
![]() | 1 klo424 2024-01-11 15:18:44 +08:00 没啥大问题,适合接口较少的情况。 |
![]() | 2 Akitora 2024-01-11 15:20:11 +08:00 via Android POST /grpc/namespace.service |
![]() | 3 XCFOX 2024-01-11 15:22:04 +08:00 ![]() 你是否在找 GraphQL ? |
4 coderxy 2024-01-11 15:24:48 +08:00 让客户端跟服务端建立一个 tcp 长连接,所有的请求都走这个连接都没啥问题, 只要能业务跑起来。 |
![]() | 5 tomatocici2333 2024-01-11 15:25:00 +08:00 比较少随便搞 |
![]() | 6 pengtdyd 2024-01-11 15:35:25 +08:00 GraphQL + 1 |
![]() | 7 feitxue 2024-01-11 15:42:27 +08:00 之前有家公司接入的三方接口就是这样设计的,所有功能的入口都是一个“/api/course.api.php”,每一个不同功能,get 参数和 requestbody 都不同。 反正能用就行。不知道他们怎么维护的。 有兴趣可以围观他们的文档 https://docs.eeo.cn/api/zh-hans/user/registerMultiple.html |
8 14v45mJPBYJW8dT7 2024-01-11 15:43:50 +08:00 ![]() 你是否在找 jsonrpc https://www.jsonrpc.org/specification |
![]() | 9 michaelliuyang 2024-01-11 15:49:44 +08:00 我们的产品比较大,接口也较多。没有使用 rest 规范(之前是,改过来了)。API 只有 GET 和 POST ,不允许 Path Variable 传参,GET 参数必须是 Params 方式,POST 参数必须是 Body 的 JSON 方式。这样相对比较好维护,在 AOP 切面做事情,标准少,且统一。 |
10 shyangs 2024-01-11 15:51:24 +08:00 可以. 你可以在 PPT 是 JSON-RPC / GraphQL 得高大上. |
![]() | 11 InDom 2024-01-11 15:51:40 +08:00 ![]() 没区别,相当于重新实现了某些 path 到 route 的过程而已。 |
![]() | 12 sss15 2024-01-11 16:15:16 +08:00 顺丰开放平台的 api 接口就是这种模式,根据业务 code 来判断你请求的什么接口 |
![]() | 14 justfindu 2024-01-11 16:18:35 +08:00 有啥区别? |
![]() | 15 LuckyHJH 2024-01-11 16:23:55 +08:00 开发上没啥问题,但是要排查问题或者统计数据的时候会不会麻烦点。譬如某个业务超时了,如何定位?统计请求量的时候是不是还得自己实现? |
![]() | 16 rb6221 2024-01-11 16:26:00 +08:00 ![]() 这样的话后端开发的时候就是几十上百个 if else 写成一坨了。作为后端你能接受就好 |
![]() | 17 rpWQTyfsAjMCKgPA 2024-01-11 16:29:49 +08:00 还有一个就是可读性?仅靠 code 区分功能,没有什么语义,api 多了难以通过 api 判断功能。 |
![]() | 18 adoal 2024-01-11 16:35:50 +08:00 ![]() 技术品位和艺术审美一样,是要通过见多识广来提升的。 |
19 lllllliiii 2024-01-11 16:37:03 +08:00 有区别吗? |
20 fancy2020 2024-01-11 16:39:56 +08:00 能用,但不优雅 |
21 lovelylain 2024-01-11 16:43:11 +08:00 看你们基础设施,如果监控、频限等都是接口维度,只用一个接口导致都上报到这个接口的话,建议拆分多个接口,如果本身支持根据 code 处理或者小改就能实现,只用一个接口也没啥问题。 |
![]() | 22 huihuiHK 2024-01-11 16:46:14 +08:00 简版 Gateway |
![]() | 23 woodfizky 2024-01-11 16:49:27 +08:00 请求 url 一样的坏处: 排障的时候如果看不到请求内容,无法通过 url 本身判断每个请求在干嘛,因为都是一样的。 (除非你都是 query_param 或者 path_param 传参,但是这样我觉得太蠢了) 同理,所有基于 url 去做的东西你们都做不了了,权限控制,访问统计,等等。 当然如果你的系统不会遇到上面的需求或者问题,那好像没啥毛病。 |
![]() | 24 nhhjhwiner 2024-01-11 16:51:43 +08:00 alipay 的 api 看上去就是一个接口,通过不同方法名进行路由的 |
25 Blank10030 2024-01-11 16:56:34 +08:00 功能少的话可以,功能多起来后还是按服务拆分接口比较符合大众要求。 |
![]() | 27 vibbow 2024-01-11 17:02:28 +08:00 你是否在找:SOAP |
![]() | 28 Vegetable 2024-01-11 17:12:26 +08:00 ![]() 你将基础设施的功能用自己的代码实现了一遍,引入了更多风险,但是好处几乎没有。 |
29 wxq844688550 2024-01-11 17:17:52 +08:00 |
![]() | 30 go522000 2024-01-11 17:38:42 +08:00 这样的话,后期要加 API 网关比较麻烦。 |
![]() | 31 lbunderway OP @batchfy 每个 code 肯定是要些注释的 |
![]() | 32 lc5900 2024-01-11 18:26:50 +08:00 我们有个项目和华子对接就是这样,接口他们定的 |
33 dyllen 2024-01-11 19:21:06 +08:00 支付宝的接口不就这样吗?就一个 gateway 的地址,所有接口都是这个地址。 |
34 bsg1992 2024-01-11 19:23:15 +08:00 就是 JSON-RPC 其实倒是也可以,这样做的坏处就是,一些成熟的中间件,没法使用 |
![]() | 35 siweipancc 2024-01-11 20:14:23 +08:00 via iPhone spring mvc 实现原理就是这个,只有一个 web filter ,那设计就很简单了,重写 condition 解析策略就行。 回到题干,假设你不是 java 开发,你确定要这么写代码,库支持改造吗?不是不能用,是维护的问题 |
![]() | 36 SHF 2024-01-11 20:31:34 +08:00 这就是 http rpc |
![]() | 37 coinbase 2024-01-11 20:57:13 +08:00 nginx 不好缓存 post ,android 客户端或者 iOS 客户端也不好自动缓存 |
38 zhao8681286 2024-01-11 21:09:37 +08:00 上面抽一层做网关,就提供一个接口 对应 code 映射到下面服务的接口。 |
![]() | 39 Nazz 2024-01-11 21:12:18 +08:00 via Android 没毛病,JSON-RPC |
![]() | 40 Nazz 2024-01-11 21:13:29 +08:00 via Android 我现在做的项目,纯 POST 且不含动态路由 |
![]() | 41 akira 2024-01-11 22:35:26 +08:00 从代码来看,其实没太大区别 |
![]() | 42 lasuar 2024-01-11 23:42:07 +08:00 楼主看起来 web coding 经验还是足,其实你多加考虑后会发现,这与定义多个接口并没有本质上的区别(多个接口仍然可以统一使用 POST 方式)。 So ,没有必要引入楼上说的其他技术来增加复杂度。 |
![]() | 44 lasuar 2024-01-11 23:45:41 +08:00 最终如何选择要根据架构体现出来的复杂度/可读性/业务可维护性等多方面来评价,楼主先自行比较一下再做考虑。 |
![]() | 45 fkdtz 2024-01-11 23:50:02 +08:00 这不就是网关干的事么,所有请求都进网关,网关根据请求特征再决定分发给谁处理。 |
![]() | 46 IvanLi127 2024-01-12 00:03:10 +08:00 via Android 想咋搞都行,只要你把配套的开发工具都搞出来就成.... 小项目可以简单点直接硬上,大项目工具链没搞定的话调试会哭死。没有什么诡异的安全需求,不建议自立门户 |
47 dayeye2006199 2024-01-12 01:53:58 +08:00 via Android ![]() 恭喜你发明了 graphql 我的朋友 |
48 314696645142 2024-01-12 08:48:38 +08:00 能跑就行 |
49 lianglianglee 2024-01-12 09:19:5 +08:00 aliyun 的控制台和 OpenAPI 就是这样,配置化接入。 我司的 OpenAPI 也是参考这样的风格,提供了日志,告警,授权,接口方只需要关注实现即可 |
![]() | 50 sayitagain 2024-01-12 09:26:27 +08:00 @feitxue 我也搞过这样的。。。我猜是$$action(),action 参数是具体调用的方法名。。。 |
51 jonsmith 2024-01-12 09:55:30 +08:00 另类的代价是无法跟同行工具兼容,各种轮子自己造。如果不是非要如此,遵守行业规范不是更好吗? |
52 tairan2006 2024-01-12 10:21:58 +08:00 这么设计只会更复杂,何必呢 |
![]() | 53 chenzhengjian 2024-01-12 10:34:06 +08:00 这不就是网关? |
![]() | 54 Torpedo 2024-01-12 10:38:20 +08:00 想到一个好处,浏览器 get 不能发 body 。这本就导致很多中查询接口设计很难用 get 。比较难以 restful |
![]() | 55 thetbw 2024-01-12 10:45:02 +08:00 支付宝不就是这种,只有一个网关接口,然后根据请求 method 字段,网关分发到具体业务 |
56 zjcoding 2024-01-12 10:49:38 +08:00 去看下 leetcode 的接口,GraphQL |
![]() | 57 ZeroDu 2024-01-12 12:11:49 +08:00 grpc 一步到位 |
![]() | 58 est 2024-01-12 12:22:23 +08:00 ![]() sql-over-http |
![]() | 59 leojia 2024-01-12 12:52:54 +08:00 via Android 这不就是 graphql |
60 WashFreshFresh 2024-01-12 13:20:08 +08:00 我司就是这样,只能说爽的地方很爽,痛苦的地方也可很痛苦。一个接口+dubbo+反射,我感觉金融是不是都这样。 |
61 dbit 2024-01-12 13:20:34 +08:00 via Android 都是同一个路径,f12 抓接口的时候 看谁会恼火 |
62 hxysnail 2024-01-12 13:51:43 +08:00 其实重点不是一个接口还是多个接口的问题,甚至我们可以这么理解: http 协议它就是一个接口!为什么呢?通过 method 、path 、header 、body 来区分不同的业务功能,跟你通过 body 里面的 code 字段还有其他业务数据一个道理。 那么,重点是什么呢?重点是设计哲学对不同业务进行分析,总结共性,做适当抽象,并最终形成一套严谨、一贯的规则(或者说约定)。不管是 rest 风格,还是就根据 code 进行处理,都是一样的。 但话说回来,rest 确实有它的缺陷,比如用 method 来表达动作,用 statuscode 来表现结果,由于 method 和 statuscode 无法根据业务自由扩展(特别是 method ,你很难新增一种新 method ),在复杂的业务面前,有点束手束脚。其他的倒还好。 |
![]() | 63 rickiey 2024-01-12 14:12:45 +08:00 这就是 JSON-RPC ,以太坊等区块链项目就这么搞的,一个接口,后端用的反射实现的,也非常方便 |
64 zengzizhao 2024-01-12 14:44:37 +08:00 @watzds #25 是的 |
![]() | 67 yueye115 2024-01-12 15:17:09 +08:00 我感觉 GraphQL 挺好, 但是前端小哥会抱怨他们要做的工作多了 |
68 Hieast 2024-01-12 15:51:01 +08:00 只需要遵循 restful 架构,就很容易在网关层面做请求监控、报警、业务分析,否则这些都需要额外的开发量。 |
69 flytsuki 2024-01-12 15:55:29 +08:00 能用但不建议,不跟着标准来以后有其他需求就要自己造轮子 |
![]() | 70 Aresxue 2024-01-12 15:59:04 +08:00 小应用随便玩,大的这么玩,基于 http 接口的文档生成工具比如 swagger 就废了,你要自己手写接口文档还要维护,静态代码分析系统也没啥用了,一个应用就一个接口要干啥肯定不知道,全链路系统好一点,但也只能用 tid 去查,其它维度的查询都废了,监控告警系统基于接口的统计比如调用量、平均 rt 、95 线、97 线、99 线也都无了,简而言之可观测性被你全废了。 |
71 auh 2024-01-12 16:03:01 +08:00 没毛病,怎么简单怎么来。 |
![]() | 72 szdubinbin 2024-01-12 16:31:38 +08:00 ![]() 有一个微小的问题,debug 的时候,从 chrome 控制台看到全是一个 path ,我估计前端找问题急起来得疯 : )。 |
![]() | 73 james2013 2024-01-12 16:50:44 +08:00 只用一个接口对前端和后端都很恶心 前端:使用不同的接口名称,接口文档方便调试和排除问题 后端:本来接口自然是解耦的,居然要耦合在一起,写一大堆的判断和跳转,出了问题排除会更麻烦 |
74 way2create 2024-01-12 17:21:08 +08:00 @feitxue 感觉是那种非常老的 php 项目 |
75 way2create 2024-01-12 17:24:15 +08:00 你要是只用一个接口 代码都写在一起 那多了就不好维护 小的也还行 你要只是路由格式的问题 那你爱怎么用怎么用 遵守自己的规范或者公开的规范也行 说白了不就是解析路由的规则不同了 正常解析分发到不同的地方处理并不会存在楼上说的都是 if else 的情况 |
76 xiaoHuaJia 2024-01-12 17:38:38 +08:00 前端在头信息写入请求业务 code,然后后端采用策略设计模式分发到不同 server 就行了,小项目无所叼为 |
78 clow 2024-01-12 17:52:36 +08:00 GraphQL + 1 |
![]() | 79 lululau 2024-01-12 17:55:08 +08:00 这叫一个接口? example.com:443/api1, example.cm:443/api2 用的是同一台机器的同一个 TCP 端口,是不是也可以叫一个接口? |