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

[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

[14v45mJPBYJW8dT7]

你是否在找 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]

能用，但不优雅