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

[Immortal]

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

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

[kaka8wp]

对于给 app 的接口，工作上遇到的就是客户端同事觉得最好接口面向页面，不希望一个页面调用几次接口，我感觉是不是可以在服务端还是按照面向数据来做接口，给 app 包装出来一个调用多个面向数据的面向页面的接口。后面更新维护也稍微好弄点

[TangMonk]

@kulove

有时候兼容起来很困难，不得不再开一个数据库。
如果是普通 app 的话，我觉得不如直接强制更新了。
对于已经有大量的老用户的话，还是得做兼容。

http://stackoverflow.com/questions/389169/best-practices-for-api-versioning

[Eoss]

@jiangzhuo 说的是炉石吧。

[Immortal]

@kaka8wp 比如我附加的说明?你看下是不是这个意思

[kulove]

@TangMonk #42 兼容确实是问题，如果是企业内部使用倒还可以强制更新，如果对象是大众还真要仔细考虑考虑，能兼容尽量兼容

[kaka8wp]

@Immortal 对的~我觉得这个挺合理的，后续维护的话对于 app 页面调整这种，只要修改那一个有数据逻辑的接口就好，而且减少影响其他引用相同的面向数据接口的地方。
工作中几个项目都是轻量化客户端，基本上都是数据显示不做任何处理~我这样做之后同事关系明显好了~就是一有问题不管怎么样都先说是后端返回的数据问题。哈哈

[Limius]

作为 PM 我跟技术团队完成项目时也遇到过这种事，你考虑到的是性能的问题，实际上我考虑到的是如果由服务端提供 API ，客户端只做展示功能，业务抗错能力会比较强，数据计算逻辑写死在客户端，如果上线后发现需要调整，这时你只能通过更新客户端版本来修正数据展示，而 appstore 的上线审批需要几天时间，对于我们 PM 来说这几天基本是不可忍受的，特别是互金行业，涉及到金额数据的展示这种是致命的，所以宁愿计算逻辑由服务端完成，毕竟随时可改，这是我从产品角度的一些看法，供你参考。

[Limius]

@TangMonk 这个链接很好的回答了嘛

[learnshare]

补充里的三层是合理的，不过一般项目都前两层合并到一起了。甚至划分不清楚，数据和业务逻辑部分融合到一起了，难以维护。

实在有必要，就另搞一层后端，专门服务客户端。

[bombless]

我们这边倾向于尽可能让服务器端做。
其实我挺同意的，我们做 app 的让客户端节省点电量让手机续航更长一点挺好的。
我自己是负责服务端这边的。

[Immortal]

@Limius 嗯 这个问题之前没有很重视 的确很重要

[Immortal]

@learnshare 是的 现在我就是只有两层 想慢慢分出来 被坑到了..

[renshaojuncool]

我感觉应该看具体情况吧，我是做 iOS 的，一般数据处理是很希望放在服务端来做的，客户端在渲染页面之前，对请求到的数据做过度的处理，会造成反应缓慢，卡顿的感觉(当然也可以进行一些优化，做预处理)，但是考虑到 APP 健壮性，还是放在服务端处理比较好，这样造成的结果就是，如果线上出现了某个问题，我会先查是否是自己的问题或者是数据返回的问题，一般后台背锅就比较多了(虽然客户端已经做了比较多的安全处理，但是某些数据还是不可避免的会发生)，这种情况下，后台直接修改代码或数据，就可以立马结局，而如果放在客户端，就 iOS 而言，审核就够难受的了

[Limius]

@renshaojuncool 我上面回答的正是这个意思~

[sampeng]

设计到自己懒得去实现为止。就是设计 api 总有个一界限。过了界限，自己就要加班去实现。。。我个人觉得不用想太多，以加班为平衡点来是最实际的。什么？扩展性，放心好了。其他人看别人的 api 设计都是一坨屎

[Aluhao]

能 App 本地处理的，就不需要去向服务器请求；

[CFM880]

现在每次穿过的数据都要遍历一遍。。。。。

[zwhu]

也许你们想要的是 graphql

[mazyi]

写 app 应该也是有成熟的体系了，如果 app 是核心业务的话后台只是处理器而已， dirty work 自然多。

这里和 app 的性质其实有很大的关系，如果涉及较多的交互那无可厚非数据得干净，如果更多的动态变化的展示那就自己处理数据。

[Chyroc]

试试 graphql