后端接口规范问题，只提供一个接口如何？

lbunderway · 2024-01-11T07:17:15Z

一个后端服务只向外提供一个借口，全用 post ，通过定义不同的业务 code 进行处理，我之前有个小系统就这样搞过，并且我还觉得前端反而会不会简单些，只用一个接口，而有的项目用 rest 风格，有的反而有点不伦不类，大佬些觉得如何呢

接口

rest

不伦不类

Code

79 replies • 2024-01-12 17:55:08 +08:00

v2er4241

Jan 11, 2024

1

没啥大问题，适合接口较少的情况。

Akitora

Jan 11, 2024 via Android

2

POST /grpc/namespace.service

XCFOX

Jan 11, 2024

28

3

你是否在找 GraphQL ？

coderxy

Jan 11, 2024

4

让客户端跟服务端建立一个 tcp 长连接，所有的请求都走这个连接都没啥问题，只要能业务跑起来。

tomatocici2333

Jan 11, 2024

5

比较少随便搞

pengtdyd

Jan 11, 2024

6

GraphQL + 1

feitxue

Jan 11, 2024

7

之前有家公司接入的三方接口就是这样设计的，所有功能的入口都是一个“/api/course.api.php”，每一个不同功能，get 参数和 requestbody 都不同。
反正能用就行。不知道他们怎么维护的。
有兴趣可以围观他们的文档 https://docs.eeo.cn/api/zh-hans/user/registerMultiple.html

14v45mJPBYJW8dT7

Jan 11, 2024

1

8

你是否在找 jsonrpc https://www.jsonrpc.org/specification

michaelliuyang

Jan 11, 2024

9

我们的产品比较大，接口也较多。没有使用 rest 规范（之前是，改过来了）。API 只有 GET 和 POST ，不允许 Path Variable 传参，GET 参数必须是 Params 方式，POST 参数必须是 Body 的 JSON 方式。这样相对比较好维护，在 AOP 切面做事情，标准少，且统一。

shyangs

Jan 11, 2024

10

可以.

你可以在 PPT 寫這是 JSON-RPC / GraphQL 顯得高大上.

InDom

Jan 11, 2024

8

11

没区别，相当于重新实现了某些 path 到 route 的过程而已。

pushMeUp

Jan 11, 2024

12

顺丰开放平台的 api 接口就是这种模式，根据业务 code 来判断你请求的什么接口

djkloop

Jan 11, 2024

13

@feitxue 只要我参数够多，就没有完不成的需求

justfindu

Jan 11, 2024

14

有啥区别?

LuckyHJH

Jan 11, 2024

15

开发上没啥问题，但是要排查问题或者统计数据的时候会不会麻烦点。譬如某个业务超时了，如何定位？统计请求量的时候是不是还得自己实现？

rb6221

Jan 11, 2024

1

16

这样的话后端开发的时候就是几十上百个 if else 写成一坨了。作为后端你能接受就好

rpWQTyfsAjMCKgPA

Jan 11, 2024

17

还有一个就是可读性？仅靠 code 区分功能，没有什么语义，api 多了难以通过 api 判断功能。

adoal

Jan 11, 2024

10

18

技术品位和艺术审美一样，是要通过见多识广来提升的。

lllllliiii

Jan 11, 2024

19

有区别吗？

fancy2020

Jan 11, 2024

20

能用，但不优雅

lovelylain

Jan 11, 2024

21

看你们基础设施，如果监控、频限等都是接口维度，只用一个接口导致都上报到这个接口的话，建议拆分多个接口，如果本身支持根据 code 处理或者小改就能实现，只用一个接口也没啥问题。

huihuiHK

Jan 11, 2024

22

简版 Gateway

woodfizky

Jan 11, 2024

23

请求 url 一样的坏处：
排障的时候如果看不到请求内容，无法通过 url 本身判断每个请求在干嘛，因为都是一样的。
（除非你都是 query_param 或者 path_param 传参，但是这样我觉得太蠢了）

同理，所有基于 url 去做的东西你们都做不了了，权限控制，访问统计，等等。

当然如果你的系统不会遇到上面的需求或者问题，那好像没啥毛病。

nhhjhwiner

Jan 11, 2024

24

alipay 的 api 看上去就是一个接口，通过不同方法名进行路由的

Blank10030

Jan 11, 2024

25

功能少的话可以，功能多起来后还是按服务拆分接口比较符合大众要求。

watzds

Jan 11, 2024

26

@janus77 #16 那肯定要写成按 code 注册到一个 map 里，不同 code 调用不同执行器

vibbow

Jan 11, 2024

27

你是否在找：SOAP

Vegetable

Jan 11, 2024

2

28

你将基础设施的功能用自己的代码实现了一遍，引入了更多风险，但是好处几乎没有。

blackfat

Jan 11, 2024

29

https://console.bce.baidu.com/easydl/datav/imgcls/label/groups 百度也是这么搞得

go522000

Jan 11, 2024

30

这样的话，后期要加 API 网关比较麻烦。

lbunderway

OP

Jan 11, 2024

31

@batchfy 每个 code 肯定是要些注释的

lc5900

Jan 11, 2024

32

我们有个项目和华子对接就是这样，接口他们定的

dyllen

Jan 11, 2024

33

支付宝的接口不就这样吗？就一个 gateway 的地址，所有接口都是这个地址。

bsg1992

Jan 11, 2024

34

就是 JSON-RPC 其实倒是也可以，这样做的坏处就是，一些成熟的中间件，没法使用

siweipancc

Jan 11, 2024 via iPhone

35

spring mvc 实现原理就是这个，只有一个 web filter ，那设计就很简单了，重写 condition 解析策略就行。
回到题干，假设你不是 java 开发，你确定要这么写代码，库支持改造吗？不是不能用，是维护的问题

SHF

Jan 11, 2024

36

这就是 http rpc

coinbase

Jan 11, 2024

37

nginx 不好缓存 post ，android 客户端或者 iOS 客户端也不好自动缓存

zhao8681286

Jan 11, 2024

38

上面抽一层做网关，就提供一个接口对应 code 映射到下面服务的接口。

Nazz

Jan 11, 2024 via Android

39

没毛病，JSON-RPC

Nazz

Jan 11, 2024 via Android

40

我现在做的项目，纯 POST 且不含动态路由

akira

Jan 11, 2024

41

从代码来看，其实没太大区别

freemoon

Jan 11, 2024

42

楼主看起来 web coding 经验还是足，其实你多加考虑后会发现，这与定义多个接口并没有本质上的区别（多个接口仍然可以统一使用 POST 方式）。

So ，没有必要引入楼上说的其他技术来增加复杂度。

freemoon

Jan 11, 2024

43

@lasuar #42 足=》不足

freemoon

Jan 11, 2024

44

最终如何选择要根据架构体现出来的复杂度/可读性/业务可维护性等多方面来评价，楼主先自行比较一下再做考虑。

fkdtz

Jan 11, 2024

45

这不就是网关干的事么，所有请求都进网关，网关根据请求特征再决定分发给谁处理。

IvanLi127

Jan 12, 2024 via Android

46

想咋搞都行，只要你把配套的开发工具都搞出来就成....
小项目可以简单点直接硬上，大项目工具链没搞定的话调试会哭死。没有什么诡异的安全需求，不建议自立门户

dayeye2006199

Jan 12, 2024 via Android

1

47

恭喜你发明了 graphql 我的朋友

314696645142

Jan 12, 2024

48

能跑就行

lianglianglee

Jan 12, 2024

49

aliyun 的控制台和 OpenAPI 就是这样，配置化接入。

我司的 OpenAPI 也是参考这样的风格，提供了日志，告警，授权，接口方只需要关注实现即可

sayitagain

Jan 12, 2024

50

@feitxue 我也搞过这样的。。。我猜是$$action(),action 参数是具体调用的方法名。。。

jonsmith

Jan 12, 2024

51

另类的代价是无法跟同行工具兼容，各种轮子自己造。如果不是非要如此，遵守行业规范不是更好吗？

keenkiller

Jan 12, 2024

52

这么设计只会更复杂，何必呢

chenzhengjian

Jan 12, 2024

53

这不就是网关？

Torpedo

Jan 12, 2024

54

想到一个好处，浏览器 get 不能发 body 。这本就导致很多中查询接口设计很难用 get 。比较难以 restful

thetbw

Jan 12, 2024

55

支付宝不就是这种，只有一个网关接口，然后根据请求 method 字段，网关分发到具体业务

zjcoding

Jan 12, 2024

56

去看下 leetcode 的接口，GraphQL

ZeroDu

Jan 12, 2024

57

grpc 一步到位

est

Jan 12, 2024

1

58

sql-over-http

leojia

Jan 12, 2024 via Android

59

这不就是 graphql

WashFreshFresh

Jan 12, 2024

60

我司就是这样，只能说爽的地方很爽，痛苦的地方也可很痛苦。一个接口+dubbo+反射，我感觉金融是不是都这样。

dbit

Jan 12, 2024 via Android

61

都是同一个路径，f12 抓接口的时候看谁会恼火

hxysnail

Jan 12, 2024

62

其实重点不是一个接口还是多个接口的问题，甚至我们可以这么理解： http 协议它就是一个接口！为什么呢？——通过 method 、path 、header 、body 来区分不同的业务功能，跟你通过 body 里面的 code 字段还有其他业务数据一个道理。

那么，重点是什么呢？重点是设计哲学——对不同业务进行分析，总结共性，做适当抽象，并最终形成一套严谨、一贯的规则（或者说约定）。不管是 rest 风格，还是就根据 code 进行处理，都是一样的。

但话说回来，rest 确实有它的缺陷，比如用 method 来表达动作，用 statuscode 来表现结果，由于 method 和 statuscode 无法根据业务自由扩展（特别是 method ，你很难新增一种新 method ），在复杂的业务面前，有点束手束脚。其他的倒还好。

rickiey

Jan 12, 2024

63

这就是 JSON-RPC ，以太坊等区块链项目就这么搞的，一个接口，后端用的反射实现的，也非常方便

zengzizhao

Jan 12, 2024

64

@watzds #25 是的

SenLief

Jan 12, 2024

65

@feitxue classin 这个奇葩，我之前看还有点奇怪。

SenLief

Jan 12, 2024

66

@janus77 先判断一手 code 呗，就像出错的 error 不也都是用 code 。

yueye115

Jan 12, 2024

67

我感觉 GraphQL 挺好, 但是前端小哥会抱怨他们要做的工作多了

Hieast

Jan 12, 2024

68

只需要遵循 restful 架构，就很容易在网关层面做请求监控、报警、业务分析，否则这些都需要额外的开发量。

flytsuki

Jan 12, 2024

69

能用但不建议，不跟着标准来以后有其他需求就要自己造轮子

Aresxue

Jan 12, 2024

70

小应用随便玩，大的这么玩，基于 http 接口的文档生成工具比如 swagger 就废了，你要自己手写接口文档还要维护，静态代码分析系统也没啥用了，一个应用就一个接口要干啥肯定不知道，全链路系统好一点，但也只能用 tid 去查，其它维度的查询都废了，监控告警系统基于接口的统计比如调用量、平均 rt 、95 线、97 线、99 线也都无了，简而言之可观测性被你全废了。