app后端开发六：API设计的思考

待我称王封你为后i 2022-08-09 06:54 232阅读 0赞

职业生涯中第二个APP服务端开发算是告一段落了，今天难得半天闲，是时候做一做这一次的总结、反思一些得失。

# 一、 一切都会更好 #

在从事APP服务端开发的这一年里，从懵懵懂懂的摸索，到今天基本能够独自设计接口、数据库。完成codeing。学到了很多的新技能，也在这个过程中认识到，自己技术上的不足，团队对于个人的重要性。不说这些废话，这些对自我的吐槽留在夜深人静的时候独自吐槽吧！今天主要还是先说一说在本次开发中我设计API考虑的出发点。

*ps：我相信在不断的codeing、thinking后会越来越好！*

# 二、设计API不要忘记这些点 #

## 2.１ 多平台通用性 ##

这一点其实有时候也是要看项目的业务，如果你们的业务确定只会在IOS平台上发展(当然这种情况应该不多)，那么你考虑Android就没有多大必要性。  
一般来讲，我们至少需要考虑三个端：ios、android、web。所以在做接口时，首先需要做到如何标识这三个接口？以及他们业务流程是否全部一致？通信协议如何选取(当然首选http，成本低，开发快)？

这里多说一点，http的好处是成本低，以前web开发者能够很快掌握转型，比如说我。当然它的性能肯定就不会特别好，都知道它是短连接、无状态。因此最近打算学学 **workerman**。

## 2.2 app应该快速的作出响应 ##

我记得之前在看微博架构演进过程中，从最初的10s到现在的3s以内。历程充满血与泪呀。不过这一切都是值得的，为了让我们自己开发的app飞起来，我们要历经寒暑、跨越坎坷，以决不放弃的态度坚持下去。  
这里对于app响应速度，历程大概是这样：

*  最初版本满足所有的功能为主：由于用户量不大，所以这时候性能不会出太大问题，做好数据库应该就OK啦
 *  下一个版本，有了一点点用户，性能成为困扰，那么请记得用缓存，redis的解决方案在微博性能优化过程中起了不可磨灭的作用
 *  在后面，用户更多了，那么也许应该早点牛人，规划下代码的架构，搞点负载均衡。考虑下CDN等等，这些事情我也不太懂啦，学习，学习，学习(重要的事情需要说三遍)

## 2.3 充分考虑移动端的特性 ##

在 2.1 中说了，要考虑跨平台的特性，但是毕竟我们的主要方向是：移动互联网，所有重心应该以移动端为主。比如：移动端的反应速度(算是对2.2的补充)，耗电量，流量使用情况等等

**先说说响应速度：**  
由于移动端网络会有：3G、4G、wifi等(请不要说还有2G，如果你还用2G，那么你怎么跟上移动互联网飞一般的步伐呢？)  
除了上面2.2提到的提高响应速度的技术层面的东西，还有一些技巧可以使用，让用户感觉很快。首先，我们假设使用HTTP协议，那么大家都清楚，HTTP每一次链接都会耗时很久，所以每一次链接都是宝贵的，要返回尽可能合适的数据。  
这里举个栗子。现在很多APP首页进去都是列表，从列表中选择一个项目点击进去后会是详情。从描述来看这里需要两次链接，然后其实我们可以通过一次链接来完成，当请求列表时，同时返回列表中每一个项目的详细情况，那么用户进入详情页时，就可以做到秒开了。当然至于列表中是否需要每一个都返回详情，需要看你们的业务。  
如果有时候滥用预载入，会白白浪费用户很多流量，所以这里要慎重。

**帮助用户节省电量与流量：**  
帮助用户省流量是要你们业务上确定哪些业务在3G、4G网络时候可以不显示，减少用户获取信息时耗费大量的流量，不过我个人觉得这个倒不是特别重要，目前国内流量价格越来越便宜，而且免费的wifi也越来越多了。  
这里主要谈谈怎么节省电量，首先要明确哪些会耗费过多的电量。

*  链接过多会导致设备频发的发送请求，接受响应，这会加快电量的损耗，所有这里也要求一次连接尽可能做多的事情，当然别过头
 *  app内应该避免复杂的计算
 *  后台service减少唤醒CPU的次数，唤醒CPU后要尽可能做少的事情，好让CPU迅速休眠

所以总而言之，为了省电、为了让用户感觉更快，那么一次链接尽可能做更多的事情，尽可能传输更多的数据吧。

## 2.4 请求与响应的数据格式 ##

这里响应数据建议使用json，更轻量级，会节省很多流量，另外也便于解析。当然你也可以用xml或者自定义啦。

**主要说下请求的数据格式：**  
方式一：K/V形式进行http各类请求  
方式二：使用json或者xml数据进行请求  
两种方式各有优劣，方式一服务规范，便于使用RESTful，缺点是请求数据格式与响应数据格式不一致，可能会加载客户端工作量，另外RESTful要求的各类请求方式，也会让客户端有时候莫名其妙的蛋碎。  
方式二，请求响应数据格式统一，便于管理，并且url会变得更短，清晰明了。当然这也意味着，基本上所有请求都要是POST请求了，不符合RESTful的规范。

## 2.5 对安全的顾虑 ##

由于所有的接口，相当于全部都是暴露的，只要通过抓包工具，可以轻而易举的获得。首先别人想要获取到我们的接口，这个我们没有办法，那么想想办法，让他拿到接口也没有用处。怎么做？万能的加密啊

对于请求参数，如果很重要，需要防止中间被篡改，那么久需要加密，或者使用签名机制。比如获取数据第几页，这种就没有加密的必要。但是如果是获取用户的某些敏感信息，请求的参数应该加密，否则很容让张三就获取到了李四的信息。另外很多提交的数据，需要插入到数据库的数据，建议都采用加密，然后服务器解密后在进行插入到数据库。

对于响应数据，个人觉得比如列表数据，就没有加密传输的必要，因为你本来就是需要进行展示的，但是对于用户的隐私信息应该进行加密，否则就被中间人嗅探到了怎么办？  
还有诸如sql注入，重复提交等等这些都是需要考虑的。

## 2.6 为了运营与运维 ##

一个app除了考虑技术上的问题，还应该着眼于商业。  
先说说运维，运维的成本越低越好，比如：某些功能更新，会导致app不能使用，那么这个成本就大了，所以这里在app升级的过程中，需要保证老版本的可用性。另外由于app每一次提交应用市场(特别是ios)都需要一定的时间，这个阶段会导致用户不可用新功能，那么最好重头还是压在服务端，所以H5能够这么流行还是有道理的。

## 2.7 文档 文档 文档 ##

嗯，重要的事情打三遍，之前已经有了两篇博文专门说博客这个事情，这里就不再说了，放上之前文章的链接：

[swagger-ui教程-构建api接口文档工具][swagger-ui_-_api]  
[API接口文档自动生成工具][API]

# 三、开发无止境 #

在工作中，暴露了很多自己知识的空白点，接下来应该补一补各方面的知识了  
首先可能会取了解一些客户端开发的知识，也许会自己学学ios开发，不是听说swift很吊吗？  
还有缓存的应用技术，应该提高了，redis、mongodb这些都该进行一下脑补了。  
不过在学这些之前，打算先看一本书《程序员的思维修炼:开发认知潜能的九堂课》听说看了之后，学习能力会跟打了鸡血一样，直线提升，等我先看看，如果不错，我会告诉你们的。

--------------------

[app开发系列文章][app]

[swagger-ui_-_api]: http://blog.csdn.net/hel12he/article/details/46547863
[API]: http://blog.csdn.net/hel12he/article/details/46804915
[app]: http://blog.csdn.net/hel12he/article/details/47721209