移动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格式等等。
总之，要达到的目标就是让不一样的端可以很方便的使用你的接口。

二、良好的响应速度

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

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

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

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

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

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

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

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

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

固然这种preload的方案也不能滥用，若是预加载数据的命中率较低的话，也不行，白白浪费了不少的流量。

四、考虑移动端的网络状况和耗电量

若是让咱们说出哪类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有大量的计算、有很炫的视觉画面都会消耗电量， 另外，不断的移动网络连接也会消耗大量的电量，
咱们都知道移动网络是经过无线电波来通信的，那么发射装置就须要消耗必定的电量来发射和接收无线信号。
特别的是，频繁的连接会不断的切换网络设备与移动基站之间链接状态，这都会消耗一部分电量。

因此，对于接口而言，尽可能用少的连接传输多的数据，
好比，对于关于咱们、版本更新以及一些系统配置信息，彻底能够经过一次连接所有返回给客户端。

五、通用的数据交换格式

目前，对于接口和客户端的数据交换格式，基本上就是两种，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'
}

六、接口统计功能

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

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

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

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

八、隐式用户与显式用户

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

隐式用户指的是，APP程序自己就没有用户系统，或者一个在没有登陆的状况下，使用咱们APP的用户。
在这种状况下，能够经过客户端生成的UDID来标识一个用户。

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

九、安全问题 

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

传统固若金汤的网站，极可能由于接口的一点疏忽而遭受入侵。如今，在不少白帽子或者黑客的入侵思路中，

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

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

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

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

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

接口测试程序，有条件的话，也能够提供，方便先后端的调试。

十一、版本的维护

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