服务端 API 设计到什么程度算合适

[Immortal]

我是做服务端这块的,主要现在是做 API
最近工作中碰到一些不是很顺利的情况,不知道是不是我自己想法不对,在我概念里,如果不涉及到安全问题,很多数据展现上的逻辑工作都应该可以放在客户端处理.具体我也不好举例子,现在客户端(主要是 APP)的要求就是要做到他们数据是拿来就用,不用经过任何处理那种(遍历整理数据等操作).宁可增加网络请求,也不太愿意客户端自己处理掉,最好我这边都全部帮他们解决了.
我是这么想的:
1\考虑到服务器的负载,所以想把一定计算量放到客户端
2\考虑到流量,但客户端同事总说现在到处是 wifi,大家流量也很多,这些都是忽略不计的.道理也没错,但这不还有一方面是服务器的带宽么...
3\考虑到版本迭代,因为如果服务端数据处理到很细节,适用性很低,基本没法复用,一个需求本来是几个基础 api 提供的数据客户端整合处理下能解决的,需要我提供一个新接口,我不是非常乐意.当然如果整合的接口多,逻辑复杂我也愿意处理的,这里指的是很简单的那些. 客户端一个版本逻辑处理写死了,下个版本改了就改了,作为服务端每次改动要考虑到兼容性,所以我不太愿意维护这么多小接口.

有点罗嗦,也不知道有没有表达清楚意思.就是想问下大家在做 api 的时候是设计到什么尺度? 真要做到客户端拿到数据只需要展示这种程度么?

[kulove]

客户端能做且数据不重要那就客户端做，流量不用太在意但也不能滥用，接口加版本号

[Immortal]

@kulove 我大概也是这么个意思 客户端大佬们觉得 数据处理这种事情就不应该放在客户端做 这个问题每次都能争好久 接口加版本号这个懂的 想问下 你那对于每个版本的接口路由分发 做在了 web 服务器那层(比如 nginx) 还是项目的路由里 我不知道做哪里和是 我这边用 golang 写的

[dangyuluo]

大家都在推诿，做客户端的肯定想偷懒啦。

[minbaby]

@Immortal 哈哈，这个问题我遇到过，客户端的同学特别“拗”，能让我（ API ）做的都让我做，恨不得我把所有工作都做了，为了一个东西能争论很久（有这个时间早做完了），目的是让我明白我的思路是错的。恩，就这样，结果是我还在这家公司。

[Immortal]

@dangyuluo 的确有这个问题...有时候我在表达我的想法,客户端大佬们觉得我想偷懒,少写点代码...我是觉得应该做的都会去做不会推卸,不应该做(意思是不应该放在服务器处理的)就不是很乐意做,不过最后都会妥协..因为项目组 ios+安卓有 2 个大佬,而服务端就我一个小弟,百口莫辩啊

[Immortal]

@minbaby ...我现在正在遇到这个问题,大佬们心情好点就少说我两句,帮我分担点,一般都是我这边都处理掉了

[ytmsdy]

1:无关紧要的计算放在客户端，服务器的计算量能省一点是一点。如果客户量大，省下来的计算量也是很客观的
2 ：流量，先保证 app 正确可用，闲着无聊可以做流量的优化。
3 ：具体情况具体分析，如果都是 get 的请求。如果返回的数据包大，那就让客户端分多次来，数据包小那就你整理一下一个 API 返回。如果是 post ，或者是 put ， delete 涉及到数据操作的，最好在一个 api 里面做完，要不然网络中断什么的，出现脏数据是很讨厌的。

按照你的说法，客户端的同事只是想省力一点而已。

[helloccav]

我也遇到这个问题，对了，我是那个客户端

[Immortal]

@ytmsdy 对于 1,可能我自己太理想话了,想把性能上的问题在开发时候能考虑到的顺手都做了,客户端的意思是现在不用考虑这么多,等流量大了服务器啥的就多了,说不定客户端代码都重写了云云,我不知道怎么说服,三观不是很和. 2 我同意你说的,我思路主要和 1 一样,开发时候想到的想顺手做,这个优化的确可以滞后. 3 明白你的意思,对于事务操作肯定是放一个 api 处理了,这边主要是指的 get,数据整合类的逻辑,有时候需求数据可以从几个基础 API 获取自己整合,客户端不是很乐意

我也就吐槽下,他们想省力我也不是很有办法说服他们多写代码...

[Immortal]

@helloccav 可以说下你们客户端的想法...我看看我们逻辑差在哪里

[rockyou12]

还是看业务吧， app 重新发布需要用户自己更新，不像 web 这么方便，很多业务要变的话放 app 里面很不方便。除此我觉得 app 多请求几次去处理没什么问题

[Immortal]

@rockyou12 主要不是在业务逻辑上,业务逻辑因为很多涉及到安全问题,基本都放服务端了,很多问题是在展现逻辑上,这个数据要帮他们整理好,这个数据帮他们拼接好等等,但是其实是可以从 A 接口和 B 接口里获取自己整合,现在需要给他们新写一个 C 接口,我就不太愿意,一个是增加维护成本,一个就是没复用性

[helloccav]

@Immortal 我们客户端的想法就是和你题目里面那个客户端的想法一样，想要服务器端处理好各种计算，客户端只负责直接展示。在我们这个项目里服务器端的工程师自己就是这样设计的，不用客户端的工程师去提要求。
我们项目里面，服务器端和客户端的工程师的关系还是挺好的，不会为了这个吵架。

[Exin]

这种事需要一个统管前后端的上级来做决定，
因为两边都可以做、都有理，争论难休

[helloccav]

@Immortal 我自己在有些项目里开发客户端，有些项目里开发服务器端。对于一个展示要同时读 A 接口和 B 接口然后组合数据这样的情况，我们一般都是要求服务器端整合成一个 C 接口提供数据，主要原因是减少网络请求。
我们的要求是：
1 、尽量减少网络请求
2 、后期业务的调整尽量通过服务器端实现，客户端不修改。所以我们把尽可能多的计算和逻辑放在服务器端口实现。例如某个预订的总价是商品价格+服务费，这个总价的计算 就放在服务器端而不是客户端，这样以后想去掉服务费可以只改服务器，不用改客户端，免得客户端要重新上架（这个例子可能举得不太对，但我一时找不到更好的例子。）。

[learnshare]

客户端来做无关紧要的处理比较合适。服务端的 API 应该定位成可以服务于多种客户端的（ Android/iOS/Web 等），不是以某个客户端为主。

But 真的要分析具体问题，最好是有一个独立的 API 方案或者方法，服务端和客户端都按文档来，彼此不关心实现。

[xiaoyangsa]

能后台处理就后台处理吧。前台永远给他们做展示好了。
这就想 mvc 里面的 view 层一样，只做数据展示就行。
以后要换客户端的人就会简单得多。
要加入一个新的客户端平台也会很方便。

[nanlong]

1, 流量必然要考虑，必定会碰到没有 wifi 的情况，优化流量也能提高项目整体性能，何乐不为。
2, GraphQL 解决了数据组合、复用的问题。
3, 写客户端也是程序员啊，该干的、能干的不可以推诿，别给程序员丢脸。一些处理放在客户端必然能缓解后端服务器的压力，凭啥不做。

[rockyou12]

不涉及业务那你给他们写什么，难道界面改了你后台还要改？这不增加大家工作量嘛

[ideascf]

观点： 后台提供的 api 应该是面向数据的，而不是面向页面的。 面向页面的接口，一旦页面发生变动， api 就要发生对应的调整。 而且这样的接口也不够通用，会导致很多割裂的接口，这不是一个好的现象。
方案： 如果大佬讲理由讲不通，那也只得按他们的来咯。 但是你可以考虑增加一个 API gateway ， 由这个 api gateway 完成面向页面的 api 封装，向后调用面向数据的 api 。 如果前端后 node.js 的话，直接丢给他们做。