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

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

POST /grpc/namespace.service

你是否在找 GraphQL ？

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

比较少随便搞

GraphQL + 1

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

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

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

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

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

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

只要我参数够多，就没有完不成的需求
有啥区别?

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

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

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

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

有区别吗？

能用，但不优雅

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

简版 Gateway

请求 url 一样的坏处：排障的时候如果看不到请求内容，无法通过 url 本身判断每个请求在干嘛，因为都是一样的。（除非你都是 query_param 或者 path_param 传参，但是这样我觉得太蠢了）同理，所有基于 url 去做的东西你们都做不了了，权限控制，访问统计，等等。当然如果你的系统不会遇到上面的需求或者问题，那好像没啥毛病。

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

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

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

你是否在找：SOAP

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

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

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

每个 code 肯定是要些注释的

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

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

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

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

这就是 http rpc

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

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

没毛病，JSON-RPC

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

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

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

＃42 足=》不足

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

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

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

恭喜你发明了 graphql 我的朋友

能跑就行

aliyun 的控制台和 OpenAPI 就是这样，配置化接入。我司的 OpenAPI 也是参考这样的风格，提供了日志，告警，授权，接口方只需要关注实现即可

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

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

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

这不就是网关？

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

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

去看下 leetcode 的接口，GraphQL

grpc 一步到位

sql-over-http

这不就是 graphql

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

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

其实重点不是一个接口还是多个接口的问题，甚至我们可以这么理解： http 协议它就是一个接口！为什么呢？——通过 method 、path 、header 、body 来区分不同的业务功能，跟你通过 body 里面的 code 字段还有其他业务数据一个道理。那么，重点是什么呢？重点是设计哲学——对不同业务进行分析，总结共性，做适当抽象，并最终形成一套严谨、一贯的规则（或者说约定）。不管是 rest 风格，还是就根据 code 进行处理，都是一样的。但话说回来，rest 确实有它的缺陷，比如用 method 来表达动作，用 statuscode 来表现结果，由于 method 和 statuscode 无法根据业务自由扩展（特别是 method ，你很难新增一种新 method ），在复杂的业务面前，有点束手束脚。其他的倒还好。

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

＃25 是的

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

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

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

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

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

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

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

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

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

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

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

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

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

GraphQL + 1

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