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

[Immortal]

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

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

[ideascf]

补充一个连接： [微服务实战（二）：使用 API Gateway]( http://dockone.io/article/482) 或许有些帮助。

[helloccav]

@ideascf 如果 api 面向而不是面向页面，那么一个页面由很多部分组成，那就要调用好几个接口，这就大大增加了网络请求的负担。在我们的项目里面， api 都是面向页面的，一个页面尽量只请求一次 /一个 api

[hwiiago]

没有业务场景单纯谈该放哪边来计算是没有意义的。

[wizardoz]

不考虑用户的流量，我觉得是很作死的行为。
要是用户哪天打开流量统计，发现你的 app 是流量大户，说不定就卸载了。

[Immortal]

@Exin 是的 的确有发现这个问题 扁平化管理的缺陷

[Immortal]

@helloccav 明白你的意思了 这种会影响业务逻辑的改动 的确需要考虑进去 学习了

[Immortal]

@ideascf 很同意你的说法 应该面向数据而不是页面, 做着做着就做到页面的误区了.回头想了下,主要应该是一般开发没文档,都是看着页面+口头问需求的原因...

[Immortal]

@wizardoz 会有这个可能,主要用户量不上来,很多问题不愿意也可能都想不到,光凭嘴巴说服不了很尴尬

[ystop]

我觉得 一般情况下 这些逻辑是要放在后台做的。 因为 APP 发版的成本很高，而且客户端过多的接口业务反而会导致项目复杂度的提高,平时有什么 BUG,问题的,兼容的 后台直接改就好了,非常方便。 对于通用性，我觉得底层的服务代码肯定是通用的，不同的端确实是需要不同的接口的，需要加个 api 层完成面向页面的 api 封装.

[Immortal]

@helloccav 这个问题感觉又很难完全有个标准.按页面有按页面的好处,按数据也是.前者连接数是会少,后者更加灵活和容易维护.扯到最后又要扯到具体需求了,不过这种我觉得可以灵活的定,但是可以有一个侧重面

[crashX]

看你后台有几层了，如果你是中间层对接客户端应该做，如果是底层需要对接所有端那应该给客户端做。

[susucoolsama]

感觉 APP 还是面向页面写接口好啊，面向数据很蠢的，虽然通用性好，但是架不住一个页面请求好几次接口，逻辑也写在 APP 里，网络请求负担很大。

[ideascf]

@helloccav 是的，如果有多个模块，就请求多个 api ，我们目前就是按照这样的方式处理。 这样 api 在很大程度上能得到复用，这更有利于 api 维护管理。 如果全部面向页面来做 api ，我认为越往后走， api 维护以及代码维护的成本就会越来越高。 当然，这样肯定就会面临多次网络 io 的开销，但我认为在目前 4G 流行的场景这不是一个大问题。 而且如果发现这块真的是一个短板，那么可以考虑加入 API gateway 。

[ideascf]

@Immortal 要立字据啊

[Immortal]

@crashX 刚好想到这个问题,应该问题也在我分层不是很清晰.前期规划的问题.对于这个事情上我自己看来问题也很大,准备慢慢解藕

[Immortal]

@ideascf 唉 工作环境没这么理想化呢,我也想有个文档,写代码的时候只要动手动眼别动口.没办法

[jiangzhuo]

我给你讲个不是笑话的笑话——曾经有款手游，战斗动画都是服务端渲染然后以流媒体的形式传回给客户端的。

[TangMonk]

@kulove 版本号这个我觉得不是很必要，如果有大版本变动，数据结构就会有不同。如果两个版本使用同一个数据库，那么数据就会错乱的。

如果确实需要兼容老版本接口的话，还要单独做数据兼容处理。

[TangMonk]

@TangMonk 如果是类似 AWS 那种给开发者提供接口的话，就有必要加上版本号。 如果是普通的应用场景，版本号不是很必要。

[kulove]

@TangMonk #38 如果不传版本号的话就确定不了版本，如果是改变接口地址还不如传版本号方便，设计兼容新老版本的 API 我觉得是很有必要的，没有那个 APP 发布大版本后之前的版本就不能用的例子吧