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

[lbunderway]

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

[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+反射，我感觉金融是不是都这样。