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

[lbunderway]

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

[klo424]

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

[Akitora]

POST /grpc/namespace.service

[XCFOX]

你是否在找 GraphQL ？

[coderxy]

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

[tomatocici2333]

比较少随便搞

[pengtdyd]

GraphQL + 1

[feitxue]

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

[rimutuyuan]

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

[michaelliuyang]

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

[shyangs]

可以.

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

[InDom]

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

[sss15]

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

[djkloop]

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

[justfindu]

有啥区别?

[LuckyHJH]

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

[janus77]

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

[rpWQTyfsAjMCKgPA]

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

[adoal]

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

[fzdwx]

有区别吗？

[fancy2020]

能用，但不优雅

[lovelylain]

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

[huihuiHK]

简版 Gateway

[woodfizky]

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

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

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

[nhhjhwiner]

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

[Blank10030]

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

[watzds]

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

[vibbow]

你是否在找：SOAP

[Vegetable]

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

[wxq844688550]

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

[go522000]

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

[lbunderway]

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

[lc5900]

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

[dyllen]

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

[bsg1992]

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

[siweipancc]

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

[SHF]

这就是 http rpc

[coinbase]

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

[zhao8681286]

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

[Nazz]

没毛病，JSON-RPC

[Nazz]

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

[akira]

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

[lasuar]

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

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

[lasuar]

@lasuar #42 足=》不足

[lasuar]

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

[fkdtz]

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

[IvanLi127]

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

[dayeye2006199]

恭喜你发明了 graphql 我的朋友

[314696645142]

能跑就行

[lianglianglee]

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

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

[sayitagain]

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

[jonsmith]

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

[tairan2006]

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

[chenzhengjian]

这不就是网关？

[Torpedo]

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

[thetbw]

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

[zjcoding]

去看下 leetcode 的接口，GraphQL

[ZeroDu]

grpc 一步到位

[est]

sql-over-http

[leojia]

这不就是 graphql

[WashFreshFresh]

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

[dbit]

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

[hxysnail]

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

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

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

[rickiey]

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

[zengzizhao]

@watzds #25 是的

[SenLief]

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

[SenLief]

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

[yueye115]

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

[Hieast]

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

[flytsuki]

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

[Aresxue]

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

[auh]

没毛病，怎么简单怎么来。

[szdubinbin]

有一个微小的问题，debug 的时候，从 chrome 控制台看到全是一个 path ，我估计前端找问题急起来得疯 : )。

[james2013]

只用一个接口对前端和后端都很恶心
前端:使用不同的接口名称,接口文档方便调试和排除问题
后端:本来接口自然是解耦的,居然要耦合在一起,写一大堆的判断和跳转,出了问题排除会更麻烦

[way2create]

@feitxue 感觉是那种非常老的 php 项目

[way2create]

你要是只用一个接口 代码都写在一起 那多了就不好维护 小的也还行 你要只是路由格式的问题 那你爱怎么用怎么用 遵守自己的规范或者公开的规范也行 说白了不就是解析路由的规则不同了 正常解析分发到不同的地方处理并不会存在楼上说的都是 if else 的情况

[xiaoHuaJia]

前端在头信息写入请求业务 code,然后后端采用策略设计模式分发到不同 server 就行了，小项目无所叼为

[rainABC]

@feitxue 这种多了去，一个入口，后面加一个 ？ method =xxxxxxxxxxx

[clow]

GraphQL + 1

[lululau]

这叫一个接口？ example.com:443/api1, example.com:443/api2 用的是同一台机器的同一个 TCP 端口，是不是也可以叫一个接口？