App_api设计

2014年，移动APP的热度丝毫没有减退，并没有像桌面软件被WEB网站那样所取代，
不但如此，越来越多的传统应用、网站也都开始制作自己的移动APP，也就是我们常说的IOS客户端、android客户端。
这仿佛又回到了多年前的CS架构，那时候我们用VB、VC、Delphi在Windows平台上快速开发各种应用程序。
不同的是，如今的移动端APP基本上都是联网从服务器端获取各种数据，客户端只是一个简单的表现层的工具。

不仅仅是移动APP，包括面向服务的SOA架构，都需要制定一套统一、规范的接口，
那么，做这样的后端接口需要注意哪些问题呢？

1、跨平台性

所谓跨平台是指我们的接口要能够支持不同的终端，比如android、ios、windowsphone以及桌面软件、网站等，
一套接口，支持多端，就像当年Java的口号一样“Write Once,Run Anywhere”。
当然从本质上讲，服务器端的接口跟终端是没有太大关系的，只是接口应该考虑到不同端的接入成本，
采用通用的解决方案，比如通信协议就采用最常用的HTTP协议，如果是即时通信，可以采用开放的XMPP协议，
做游戏的可以采用可靠的TCP协议，除非TCP不够用了，再采用定制的UDP协议。
数据交换采用xml或者json格式等等。
总之，要达到的目标就是让不同的端能够很方便的使用你的接口。

2、良好的响应速度

如果要用一个指标来衡量接口的性能的话，那么我想最重要的就是响应速度了。
接口应该以最快的速度将数据返回给请求者。
试想，当我们打开一个页面，如果“努力加载中”之类的提示超过三五秒钟的话，
我们肯定会变得不耐烦，移动app本来大部分就是用户在碎片化时间来使用的，
在有限的时间内，用户恨不得获得的信息越多越好，即使你的app界面设计的再好，用户也不会买账。

提高响应速度又是个老生常谈的问题，大体上应该按照以下步骤来做：
初期，以功能为主，要保证功能完整，满足业务需求，这阶段可以使用动态的语言，比如java、php、asp.net等，
配合设计良好的数据库结构和索引，能满足一定的需求；
其次，随着用户的增多，可以考虑一些缓存方案，缓存是解决性能问题的万金油，通常能起到立竿见影的效果。 
最常用的静态文件缓存，memcached内存缓存等。
然后，单台机器的吞吐率不行了，通过负载均衡多加几台机器就行了。七八台机器，支持每天千万级的接口调用是可行的。
或者，直接采用CDN的解决方案，将绝大多数的静态资源交给CDN去处理。

总之，要达到的目标就是快，一个页面，秒开最好，超过三秒就需要找找原因了。

3、接口要为移动客户端考虑

接口不仅仅是提供数据和功能就完事了，更应该充分考虑移动端的特性，为移动端提供更加方便、快捷的接口。
比如，在移动端里，下拉刷新和上拉加载更多是很常见的功能，如果接口仍然按照传统的web思路，
只提供按页读取的话，就会造成移动端的额外的数据请求和计算。 这时，接口就应该针对这两种类型的操作提供额外的支持。

再比如，对于一个新闻阅读类的app来说，最新的新闻列表里的文章，特别是前几条，用户很容易点击进去看，
而后面的老的文章列表，一来用户下滑加载好几页的情况较少，二来过时的新闻用户也很少点。
如果，接口在返回新闻列表时，对于最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的内容）信息一起传给客户端，
这样，用户在打开新闻详情页的时候，就不用再从服务器端获取了，自然可以做到秒开。

比如访问第一页时，接口可以返回文章内容，如下所示 ，content=1表示加载文章内容
newslist?page=1&pagesize=20&content=1
其他页时，newslist?page=5&pagesize=20&content=0 ,不用加载文章内容。

当然，客户端要跟接口做好配合，搭配好，才能最大化的提高性能。
比如，移动端都有左右滑动来看上一篇、下一篇文章或者图片的功能，
如果，当用户请求某篇文章的时候，服务器端顺便也把下一篇文章的内容返回回来了，

那么当用户看下一篇的时候，是不是就很快了呢。

当然这种preload的方案也不能滥用，如果预加载数据的命中率较低的话，也不行，白白浪费了很多的流量。

4、考虑移动端的网络情况和耗电量

如果让我们说出哪类app比较好，可能还不大好说，但是如果让我们说出哪些app很差，
我们肯定会说出那些 体积很大、占用内存多、界面很卡、费电的app不好。

对于移动APP开发者来说， 网络流量和电池电量是不得不考虑的问题。
不过，您也许会说，这些跟接口没啥关系吧，服务器端的接口还能管得了客户端的网络流量和电量？

对于网络情况，接口应该具备为不同的网络提供不同的内容的能力，
通常，移动端的上网方式无非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，
设想一下，如果用户在流量需要花钱的情况下，你的app给用户展示了视频、音频、大量的图片而没有通知用户的情况下，
用户会怎么想，毕竟国内的流量费用还是很贵的。
还以上面的新闻列表接口为例，如果我们能够知道用户的网络情况，只有在wifi的情况下才给用户传输封面图、缩略图之类的，
是不是可以帮用户节省很多流量呢。
newslist?page=1&pagesize=20&content=1&network=wifi

对于电量，首先我们要弄清楚，app的哪些方面会消耗电量？
比如app有大量的计算、有很炫的视觉画面都会消耗电量， 另外，不断的移动网络链接也会消耗大量的电量，
我们都知道移动网络是通过无线电波来通讯的，那么发射装置就需要消耗一定的电量来发射和接收无线信号。
特别的是，频繁的链接会不断的切换网络设备与移动基站之间连接状态，这都会消耗一部分电量。

所以，对于接口而言，尽量用少的链接传输多的数据，
比如，对于关于我们、版本更新以及一些系统配置信息，完全可以通过一次链接全部返回给客户端。

5、通用的数据交换格式

目前，对于接口和客户端的数据交换格式，基本上就是两种，xml和json，而现在使用json的应该占大多数。
交换的数据包括两种，一种是客户端请求服务器端接口时传递的一些参数，一种是服务器端返回给客户端的数据。

对于客户端的请求参数，现在也越来越多的接口要求采用json的格式，而不是以往最常见的key_value对了。
比如，接口需要username和password两个参数
key_value pair的方式是：
username=hutuseng&password=hutusengpwd
然后通过GET或者POST方式传送。
而通过json方式交换数据的话，格式如下，直接POST到服务器端。
{
'username':'hutuseng',
'password':'hutusengpwd'
}

对于服务器端返回的json数据格式，需要注意两个问题：
一是汉字编码问题，因为json（javascript）内部支持Unicode编码，会将汉字等转换成unicode编码保存， 
所以在返回结果中，对于中文，可以直接输出中文，也可以输出中文的unicode编码，
json解析器都会很好的解析。 
比如下面两种方式都是可以的。
{"code":"208","data":"\u53c2\u6570\u4e0d\u5b8c\u6574"} 
{
"code": "208",
"data": "参数不完整"
}
二是字段的数据类型，特别是数字类型的，json中尽量转成数字格式，
比如
{
'userid':128
}
不要写成
{
'userid':'128'
}

6、接口统计功能

在做PC端网站的时候，我们都会给我们的网站加上个统计功能，要么自己写统计系统，要么使用第三方的比如GA、百度等。
移动端接口API则需要我们自己实现统计功能，
这时就需要我们尽可能多的收集客户端的信息，除了传统的IP、User-Agent之外，还应该收集一些移动相关的信息，
比如
手机操作系统，是android还是ios，都是什么版本，
用户使用的网络状况，是2G、3G、4G还是WIFI
客户端APP是什么版本信息。

这样，有助于我们更好的了解我们用户的使用情况。

7、客户端与服务端的肥瘦平衡

在以前C/S、B/S架构时，我们就已多次讨论过这个问题，客户端是瘦点好还是肥点好，当然也没有固定答案，需要自己根据实际情况去做权衡。
但是，在移动开发中，由于客户端的修改会很费时费力，特别是IOS应用还要经过Apple审核，
另外，当前IOS开发人员、Android开发人员的人工成本普遍较高，人才紧缺，
基于这两点，能在服务器端实现的功能就不要放在客户端，毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。

8、隐式用户与显式用户

显式用户和隐式用户，我不知道这两个词用的是否确切。 
显式用户指的是，APP程序中有用户系统，一个username、password正确的合法用户，称之为显式的用户，
通常显式用户都需要注册，登录以后能完成一些个人相关的操作。

隐式用户指的是，APP程序本身就没有用户系统，或者一个在没有登录的情况下，使用我们APP的用户。
在这种情况下，可以通过客户端生成的UDID来标识一个用户。

有了用户信息，我们就能够了解不同用户的使用习惯，而不仅仅是全体用户的一个整体的统计信息，
有了这些个体的信息之后，就可以做一些用户分群、个性化推荐之类的事情。

9、安全问题 

网络安全已经从桌面互联网转到了移动互联网，从客户端蔓延到了接口API中。

传统固若金汤的网站，很可能因为接口的一点疏忽而遭受入侵。现在，在很多白帽子或者黑客的入侵思路中，

先看看移动端接口是否存在漏洞，再看网站是否有漏洞。

客户端APP与接口的通信很容易被得到，只要在中间路由上嗅探一下就行，
whireshark、tcpdump这类工具使得这项工作变得简单无比。

所以，接口的安全工作不能马虎，暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,
如果数据特别敏感，可以考虑采用SSL/TLS等加密传输，或者客户端、服务器端约定一个加密算法和密钥，对来往传输的数据进行加密、解密
如果不采用RESTful API，可以采用基于WSDL和SOAP的Web Service的安全措施。

10、良好的接口说明文档和测试程序

接口文档有时候是项目初期就定下来的，前后端开发人员按照接口规范开发，
有的是接口开发完成后写的。
接口文档要清晰、明了，包含多少个接口，每个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。

接口测试程序，有条件的话，也可以提供，方便前后端的调试。

11、版本的维护

随着业务的变化，客户端APP和服务器端API都会发生变化，增加新的功能，修改已有的功能，
增加功能还好说， 如果是接口需要修改，那么就面临着同一个接口要同时为不同版本的客户端服务的问题。
因此，服务器端接口也要做好相应的版本维护。

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

在新浪微博的app中，从别的页面进入主页，在没有网络的情况下，首页中的已经收到的微博还是能显示的，这显然是把相关的数据存储在app本地。

使用数据的app本地存储，能减少网络的流量，同时极大提高了用户的体验（想想，很多数据都能在app本地获取，显示的速度当然快）。使用了本地存储后，需要考虑的是数据的增量更新方案。

什么是数据的增量更新？假设，用户A的首页在数据表中是有40条数据，id1-40，app每次获取10条数据。第一次运行，app从数据表获取了id1-10条数据同时存储在本地。假设用户离开了这个页面再回到首页，这时app需要再次从数据库中获取数据，由于之前已经有10条数据（id1-10）存储在app本地了，那么现在需要从数据库中获取的10条数据就是从剩余的30条中数据获取（id11-40）后并保存在app本地。这个就是增量更新的典型例子。

增量更新的原理是在数据库中，每条数据都必须有update_time这个值，记录数据最后更新的时间，当app从服务器获取了一次数据后（返回的数据必须按时间排序，update_time最近的在第一条），记录下第一条数据的update_time，当再次获取数据就只需要获取上个时间点到访问服务器这刻为止所更新的数据即可。

因为分页机制的存在，这个算法实现起来是挺多需要注意的地方，下面我举一个简化的例子详细说明：

一些假设：

1. app每次请求都带4个参数

http://test/api/timeline?count=3&page=1&since=1100&max=1200

count: 每页的显示条数（默认为3）

page: 当前页码（默认为1）

since: 时间戳，若指定此参数，则返回时间戳大于等于since的结果（应该是上次获取的最新数据的update_time）

max: 时间戳，若指定此参数，则返回时间戳少于等于max的结果（应该是发送时的时间）

在sql的查询时，使用条件 since<=update_time<= max

2. api 返回的数据包含

{

"size": 10,   //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）

"total": 284,  //应该返回的总数据量

"page": 1,

"count": 3,

"max": 0, //max为获取的最后一条数据的update_time

"since": 0

},

{ //返回的数据实体

data:.......

}

3. app存储的本地数据中的update_time是指服务器中的这条数据的更新时间，不是指app中这条数据的更新时间。

现在开始讨论：

（1）当app安装完毕后还没启动，服务器的数据表中的数据为3条，app存储的本地数据为空

服务器的数据表的数据

id	update_time
1	1100
2	1101
3	1101

app存储的本地数据

id	update_time

（2）当app第一次运行（时间为11：05），因为是第一次运行，since为0，max为现在的时间点1105，在服务器的数据表中获取所有数据。

发送的请求为：http://test/api/timeline?count=3&page=1&since=0&max=1105

（3）从（2）中发送请求后，api的返回数据，服务器的数据表中的数据，app存储的本地数据如下：

api返回的数据

{

"size": 3,   //实际返回的数据量

"total": 3,  //应该返回的总数据量

"page": 1,

"count": 3,

"max": 1101,

"since":0

},

{ //返回的数据实体

data:.......

}

服务器的数据表的数据

id	update_time
1	1100
2	1101
3	1101

app存储的本地数据

id	update_time
1	1100
2	1101
3	1101

这里是策略的重点（1）： api返回数据中的max必须为最后一条数据的update_time

（4）现在的时间是11:20，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：

服务器的数据表的数据

id	update_time
1	1100
2	1101
3	1101
4	1118
5	1118
6	1119
7	1119

可看到，比起上次拉取数据的时候，服务器的数据表多了id为4,5,6,7的数据。

这时发送api请求，策略的重点（2）：当api的返回数据size=total时，since值比上次获取大一点，因为这时数据已经获取完整了，没必要重复获取数据上次已经获取的数据（记得条件since<=update_time<= max 吗？）所以since值设置为1101+1=1102，max为现在的时间点：1120，请求的url如下：

http://test/api/timeline?count=3&page=1&since=1102&max=1120

发送请求后api的返回数据和app存储的本地数据如下：

api返回的数据

{

"size": 3,   //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）

"total": 4,  //应该返回的总数据量

"page": 1,

"count": 3,

"max": 1119,

"since":1102

},

{ //返回的数据实体

data:.......

}

app的数据：

id	update_time
1	1100
2	1101
3	1101
4	1118
5	1118
6	1119

这里是策略的重点（3）：在数据库中，update_time为1101~1120的数据有4条，但由于分页的缘故，只获取了3条（从size和total参数可以判定），这意味着1101~1120这段时间的数据没有获取完整，app所获取的最后一条数据的update_time是1119，服务器的数据表中剩下的没有被app获取的数据有两种情况：

a.update_time刚好是1119

b.update_time大于1119

 

   由于我们没法判断属于哪种种情况，如果我们下次拉数据的时候 since大于1119，服务器的数据表中id为7的数据不会再获取，那么会造成app中丢失了id为7的数据，所以针对上次数据获取不完整的情况，下次获取数据时since必须是等于1119，虽然有可能会获取重复的数据。

（5）现在的时间是11:30，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：

服务器的数据表的数据

id	update_time
1	1100
2	1101
3	1101
4	1118
5	1118
6	1119
7	1119
8	1120

这时发送api请求，这里是策略的重点（4）：当api的返回数据size少于total，为了避免有数据丢失，since为上次收到api的返回数据的max值：1119，max为现在的时间点：1130。关于策略重点（4），请结合策略的重点（3）一起理解。

 

请求的url如下：

http://test/api/timeline?count=3&page=1&since=1119&max=1130

发送请求后api的返回数据和app存储的本地数据如下：

api返回的数据

{

"size": 3,   //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）

"total": 3,  //应该返回的总数据量

"page": 1,

"count": 3,

"max": 1120,

"since":1119

},

{ //返回的数据实体

data:.......

}

这是策略的重点（5）：api中返回数据中id为6的数据，在app的本地数据中已经存在，对于这条数据，app端应该放弃重复插入。

最后app存储的本地数据如下：

app的数据：

id	update_time
1	1100
2	1101
3	1101
4	1118
5	1118
6	1119
7	1119
8	1120

ok，整个增量更新的策略已经分析完毕了。在这个策略中，page参数几乎没用，之所以要保留，是为了兼容分页不带since,max的情况。对于这个增量更新的策略，请仔细理解策略的重点（1）（2）（3）（4）（5）的分析。

增量更新的策略，还要处理一个删除数据的同步问题。假设，在服务器的数据表要删除一条数据，怎么通知app本地也删除这条数据。我们的解决方案是服务器的服务器的数据表中增加一个标识is_delete，当需要在业务逻辑上删除的时候，把这条数据的is_delete设为1，同时更新update_time。当app增量更新检测到这条is_delete为1的数据，就在app本地数据中把这条数据删除。为了避免在服务器保存太多的数据，在服务器设置一个crontab，定期把那些已经标识is_delete设为1已经一段时间的数据删除。

这个增量更新的策略，适用于需要分页显示的app页面。

app后端系列文章总目录

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

相关链接：

APP服务端API设计应该考虑到的问题

app后端设计(10)--数据增量更新