这是一个创建于 659 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个后端服务只向外提供一个借口，全用 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  28
你是否在找 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 1
你是否在找 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 8
没区别，相当于重新实现了某些 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 1
这样的话后端开发的时候就是几十上百个 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 10
技术品位和艺术审美一样，是要通过见多识广来提升的。
|
 |
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 2
你将基础设施的功能用自己的代码实现了一遍，引入了更多风险，但是好处几乎没有。
|
 |
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 1
恭喜你发明了 graphql 我的朋友
|
 |
48
314696645142 2024-01-12 08:48:38 +08:00
能跑就行
|
 |
49
lianglianglee 2024-01-12 09:19:54 +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 1
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 1
有一个微小的问题，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.com:443/api2 用的是同一台机器的同一个 TCP 端口，是不是也可以叫一个接口？
|
Select Language