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

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

一、 一切都会更好

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

ps:我相信在不断的codeing、thinking后会越来越好!

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

2.1 多平台通用性

这一点其实有时候也是要看项目的业务,如果你们的业务确定只会在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接口文档工具
API接口文档自动生成工具

三、开发无止境

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


app开发系列文章

你可能感兴趣的:(app开发)