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

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

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

lovebirdegg

2017-02-14 08:50:02 +08:00

逻辑处理放在服务端比较好，放在客户端维护起来太不方便了。

wupher

2017-02-14 09:42:17 +08:00

一般而言，数据和逻辑是放到服务端，展示层是客户端的事，这是大原则。

在可能的基础上，尽量提高接口的友好程度，方便客户端拿到数据后能方便处理，这是原则 2 。

流量是肯定要考虑的，我自己也做 iOS 客户端，他这么说肯定是瞎扯。现在弱网络，如地铁，火车、汽车等情况其实相较以前更常见了。本地在可能的情况下，都是要做 cache 的。

理由 3 ，我倒觉得未必成立。其实，数据实际传输的时间消耗不一定高，往往是链接建立的耗时更高。所以一般建议，尽量一个请求搞定数据，而不要让客户端连续调用多个 http 请求来为一个界面加载数据。如果服务端只是将几个 http 请求包起来，统一做个门面，其实这事也不难。比客户端回调套回调好处理多了。

adoyle

2017-02-14 10:18:39 +08:00

只能协商。逻辑放在客户端或者服务端 (gateway) 里实现并没有绝对的定论，因为这都包含了业务逻辑。以固有逻辑来定论我觉得都是错误的，要根据具体场景、团队、业务逻辑来判断放哪实现**最为合适**。业务逻辑是难以根据平台区分的。协商会有几点考虑因素：

1. 安全性。有些数据只能在服务端计算。
2. 性能开销。根据不同场景，可以放在客户端，也可以放在服务端。
3. 可复用性。业务逻辑实现在客户端，就难以复用了；但实现在服务端，又要考虑通用性。
4. 人为因素。观点争执不下，沟通成本太高等等。

我觉得解决这个问题的最好办法，不是讨论这块逻辑究竟该放哪里。因为每个新 feature 都得讨论一遍接口，会非常麻烦。
而是应该由一个人去负责一个 feature 的完成，由同一个人完成前后端的代码，即所谓的全栈。这样的好处在于：

1. 避免沟通交流上的争执。在编程领域，一个人干活往往比两个人效率更高。
2. 只有经历过同样的场景，才会换位思考，知道对方的难点，才会互相体谅。
3. 当一个人去实现，因为放哪做都是自己做，才更有可能去思考代码结构，真正考虑业务逻辑放哪实现**最为合适**。
4. 当一个人去跨端，会培养全局意识，对于技术发展也是有好处的。

你可能会觉得让前端来学服务端难度太大。这是有前提的，前提是你的项目架构要清晰可维护，新手进来能快速上手，当项目可维护性做得很好，有很好的结构，那么入门门槛就只在于语言了。对于学一门新语言，对稍微有点经验的开发者来说不算难事吧。待对方实现好代码后，你可以参与 code review ，把控项目质量。

barbery

2017-02-14 10:59:30 +08:00

理论上，我觉得服务器的接口是尽可能的考虑到通用性，返回基础数据，由客户端根据自己的业务需要来自行处理然后渲染出来。这个在 web 端一直没什么问题，但是自从 IOS 和 Android 出来后情况又不一样了，考虑到发包的成本，基本上服务端都要包揽了所有的数据处理的逻辑，这么搞可以理解，但是如果出现不同的平台同一个页面不同的功能设计就很尴尬了，为了不同平台的处理逻辑，又要拆分出一个接口~