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