http://blog.csdn.net/junli_chen/article/details/51180797

2014年，移動(dòng)APP的熱度絲毫沒(méi)有減退，并沒(méi)有像桌面軟件被WEB網(wǎng)站那樣所取代，

不但如此，越來(lái)越多的傳統(tǒng)應(yīng)用、網(wǎng)站也都開(kāi)始制作自己的移動(dòng)APP，也就是我們常說(shuō)的IOS客戶端、android客戶端。

這仿佛又回到了多年前的CS架構(gòu)，那時(shí)候我們用VB、VC、Delphi在Windows平臺(tái)上快速開(kāi)發(fā)各種應(yīng)用程序。

不同的是，如今的移動(dòng)端APP基本上都是聯(lián)網(wǎng)從服務(wù)器端獲取各種數(shù)據(jù)，客戶端只是一個(gè)簡(jiǎn)單的表現(xiàn)層的工具。

不僅僅是移動(dòng)APP，包括面向服務(wù)的SOA架構(gòu)，都需要制定一套統(tǒng)一、規(guī)范的接口，

那么，做這樣的后端接口需要注意哪些問(wèn)題呢？

1、跨平臺(tái)性

所謂跨平臺(tái)是指我們的接口要能夠支持不同的終端，比如android、ios、windowsphone以及桌面軟件、網(wǎng)站等，

一套接口，支持多端，就像當(dāng)年Java的口號(hào)一樣“Write Once,Run Anywhere”。

當(dāng)然從本質(zhì)上講，服務(wù)器端的接口跟終端是沒(méi)有太大關(guān)系的，只是接口應(yīng)該考慮到不同端的接入成本，

采用通用的解決方案，比如通信協(xié)議就采用最常用的HTTP協(xié)議，如果是即時(shí)通信，可以采用開(kāi)放的XMPP協(xié)議，

做游戲的可以采用可靠的TCP協(xié)議，除非TCP不夠用了，再采用定制的UDP協(xié)議。

數(shù)據(jù)交換采用xml或者json格式等等。

總之，要達(dá)到的目標(biāo)就是讓不同的端能夠很方便的使用你的接口。

2、良好的響應(yīng)速度

如果要用一個(gè)指標(biāo)來(lái)衡量接口的性能的話，那么我想最重要的就是響應(yīng)速度了。

接口應(yīng)該以最快的速度將數(shù)據(jù)返回給請(qǐng)求者。

試想，當(dāng)我們打開(kāi)一個(gè)頁(yè)面，如果“努力加載中”之類(lèi)的提示超過(guò)三五秒鐘的話，

我們肯定會(huì)變得不耐煩，移動(dòng)app本來(lái)大部分就是用戶在碎片化時(shí)間來(lái)使用的，

在有限的時(shí)間內(nèi)，用戶恨不得獲得的信息越多越好，即使你的app界面設(shè)計(jì)的再好，用戶也不會(huì)買(mǎi)賬。

提高響應(yīng)速度又是個(gè)老生常談的問(wèn)題，大體上應(yīng)該按照以下步驟來(lái)做：

初期，以功能為主，要保證功能完整，滿足業(yè)務(wù)需求，這階段可以使用動(dòng)態(tài)的語(yǔ)言，比如java、php、asp.net等，

配合設(shè)計(jì)良好的數(shù)據(jù)庫(kù)結(jié)構(gòu)和索引，能滿足一定的需求；

其次，隨著用戶的增多，可以考慮一些緩存方案，緩存是解決性能問(wèn)題的萬(wàn)金油，通常能起到立竿見(jiàn)影的效果。

最常用的靜態(tài)文件緩存，memcached內(nèi)存緩存等。

然后，單臺(tái)機(jī)器的吞吐率不行了，通過(guò)負(fù)載均衡多加幾臺(tái)機(jī)器就行了。七八臺(tái)機(jī)器，支持每天千萬(wàn)級(jí)的接口調(diào)用是可行的。

或者，直接采用CDN的解決方案，將絕大多數(shù)的靜態(tài)資源交給CDN去處理。

總之，要達(dá)到的目標(biāo)就是快，一個(gè)頁(yè)面，秒開(kāi)最好，超過(guò)三秒就需要找找原因了。

3、接口要為移動(dòng)客戶端考慮

接口不僅僅是提供數(shù)據(jù)和功能就完事了，更應(yīng)該充分考慮移動(dòng)端的特性，為移動(dòng)端提供更加方便、快捷的接口。

比如，在移動(dòng)端里，下拉刷新和上拉加載更多是很常見(jiàn)的功能，如果接口仍然按照傳統(tǒng)的web思路，

只提供按頁(yè)讀取的話，就會(huì)造成移動(dòng)端的額外的數(shù)據(jù)請(qǐng)求和計(jì)算。 這時(shí)，接口就應(yīng)該針對(duì)這兩種類(lèi)型的操作提供額外的支持。

再比如，對(duì)于一個(gè)新聞閱讀類(lèi)的app來(lái)說(shuō)，最新的新聞列表里的文章，特別是前幾條，用戶很容易點(diǎn)擊進(jìn)去看，

而后面的老的文章列表，一來(lái)用戶下滑加載好幾頁(yè)的情況較少，二來(lái)過(guò)時(shí)的新聞?dòng)脩粢埠苌冱c(diǎn)。

如果，接口在返回新聞列表時(shí)，對(duì)于最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的內(nèi)容）信息一起傳給客戶端，

這樣，用戶在打開(kāi)新聞詳情頁(yè)的時(shí)候，就不用再?gòu)姆?wù)器端獲取了，自然可以做到秒開(kāi)。

比如訪問(wèn)第一頁(yè)時(shí)，接口可以返回文章內(nèi)容，如下所示 ，content=1表示加載文章內(nèi)容

newslist?page=1&pagesize=20&content=1

其他頁(yè)時(shí)，newslist?page=5&pagesize=20&content=0 ,不用加載文章內(nèi)容。

當(dāng)然，客戶端要跟接口做好配合，搭配好，才能最大化的提高性能。

比如，移動(dòng)端都有左右滑動(dòng)來(lái)看上一篇、下一篇文章或者圖片的功能，

如果，當(dāng)用戶請(qǐng)求某篇文章的時(shí)候，服務(wù)器端順便也把下一篇文章的內(nèi)容返回回來(lái)了，

那么當(dāng)用戶看下一篇的時(shí)候，是不是就很快了呢。

當(dāng)然這種preload的方案也不能濫用，如果預(yù)加載數(shù)據(jù)的命中率較低的話，也不行，白白浪費(fèi)了很多的流量。

4、考慮移動(dòng)端的網(wǎng)絡(luò)情況和耗電量

如果讓我們說(shuō)出哪類(lèi)app比較好，可能還不大好說(shuō)，但是如果讓我們說(shuō)出哪些app很差，

我們肯定會(huì)說(shuō)出那些 體積很大、占用內(nèi)存多、界面很卡、費(fèi)電的app不好。

對(duì)于移動(dòng)APP開(kāi)發(fā)者來(lái)說(shuō)， 網(wǎng)絡(luò)流量和電池電量是不得不考慮的問(wèn)題。

不過(guò)，您也許會(huì)說(shuō)，這些跟接口沒(méi)啥關(guān)系吧，服務(wù)器端的接口還能管得了客戶端的網(wǎng)絡(luò)流量和電量？

對(duì)于網(wǎng)絡(luò)情況，接口應(yīng)該具備為不同的網(wǎng)絡(luò)提供不同的內(nèi)容的能力，

通常，移動(dòng)端的上網(wǎng)方式無(wú)非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，

設(shè)想一下，如果用戶在流量需要花錢(qián)的情況下，你的app給用戶展示了視頻、音頻、大量的圖片而沒(méi)有通知用戶的情況下，

用戶會(huì)怎么想，畢竟國(guó)內(nèi)的流量費(fèi)用還是很貴的。

還以上面的新聞列表接口為例，如果我們能夠知道用戶的網(wǎng)絡(luò)情況，只有在wifi的情況下才給用戶傳輸封面圖、縮略圖之類(lèi)的，

是不是可以幫用戶節(jié)省很多流量呢。

newslist?page=1&pagesize=20&content=1&network=wifi

對(duì)于電量，首先我們要弄清楚，app的哪些方面會(huì)消耗電量？

比如app有大量的計(jì)算、有很炫的視覺(jué)畫(huà)面都會(huì)消耗電量， 另外，不斷的移動(dòng)網(wǎng)絡(luò)鏈接也會(huì)消耗大量的電量，

我們都知道移動(dòng)網(wǎng)絡(luò)是通過(guò)無(wú)線電波來(lái)通訊的，那么發(fā)射裝置就需要消耗一定的電量來(lái)發(fā)射和接收無(wú)線信號(hào)。

特別的是，頻繁的鏈接會(huì)不斷的切換網(wǎng)絡(luò)設(shè)備與移動(dòng)基站之間連接狀態(tài)，這都會(huì)消耗一部分電量。

所以，對(duì)于接口而言，盡量用少的鏈接傳輸多的數(shù)據(jù)，

比如，對(duì)于關(guān)于我們、版本更新以及一些系統(tǒng)配置信息，完全可以通過(guò)一次鏈接全部返回給客戶端。

5、通用的數(shù)據(jù)交換格式

目前，對(duì)于接口和客戶端的數(shù)據(jù)交換格式，基本上就是兩種，xml和json，而現(xiàn)在使用json的應(yīng)該占大多數(shù)。

交換的數(shù)據(jù)包括兩種，一種是客戶端請(qǐng)求服務(wù)器端接口時(shí)傳遞的一些參數(shù)，一種是服務(wù)器端返回給客戶端的數(shù)據(jù)。

對(duì)于客戶端的請(qǐng)求參數(shù)，現(xiàn)在也越來(lái)越多的接口要求采用json的格式，而不是以往最常見(jiàn)的key_value對(duì)了。

比如，接口需要username和password兩個(gè)參數(shù)

key_value pair的方式是：

username=hutuseng&password=hutusengpwd

然后通過(guò)GET或者POST方式傳送。

而通過(guò)json方式交換數(shù)據(jù)的話，格式如下，直接POST到服務(wù)器端。

{

'username':'hutuseng',

'password':'hutusengpwd'

}

對(duì)于服務(wù)器端返回的json數(shù)據(jù)格式，需要注意兩個(gè)問(wèn)題：

一是漢字編碼問(wèn)題，因?yàn)閖son（javascript）內(nèi)部支持Unicode編碼，會(huì)將漢字等轉(zhuǎn)換成unicode編碼保存，

所以在返回結(jié)果中，對(duì)于中文，可以直接輸出中文，也可以輸出中文的unicode編碼，

json解析器都會(huì)很好的解析。

比如下面兩種方式都是可以的。

{"code":"208","data":"\u53c2\u6570\u4e0d\u5b8c\u6574"}

{

"code": "208",

"data": "參數(shù)不完整"

}

二是字段的數(shù)據(jù)類(lèi)型，特別是數(shù)字類(lèi)型的，json中盡量轉(zhuǎn)成數(shù)字格式，

比如

{

'userid':128

}

不要寫(xiě)成

{

'userid':'128'

}

6、接口統(tǒng)計(jì)功能

在做PC端網(wǎng)站的時(shí)候，我們都會(huì)給我們的網(wǎng)站加上個(gè)統(tǒng)計(jì)功能，要么自己寫(xiě)統(tǒng)計(jì)系統(tǒng)，要么使用第三方的比如GA、百度等。

移動(dòng)端接口API則需要我們自己實(shí)現(xiàn)統(tǒng)計(jì)功能，

這時(shí)就需要我們盡可能多的收集客戶端的信息，除了傳統(tǒng)的IP、User-Agent之外，還應(yīng)該收集一些移動(dòng)相關(guān)的信息，

比如

手機(jī)操作系統(tǒng)，是android還是ios，都是什么版本，

用戶使用的網(wǎng)絡(luò)狀況，是2G、3G、4G還是WIFI

客戶端APP是什么版本信息。

這樣，有助于我們更好的了解我們用戶的使用情況。

7、客戶端與服務(wù)端的肥瘦平衡

在以前C/S、B/S架構(gòu)時(shí)，我們就已多次討論過(guò)這個(gè)問(wèn)題，客戶端是瘦點(diǎn)好還是肥點(diǎn)好，當(dāng)然也沒(méi)有固定答案，需要自己根據(jù)實(shí)際情況去做權(quán)衡。

但是，在移動(dòng)開(kāi)發(fā)中，由于客戶端的修改會(huì)很費(fèi)時(shí)費(fèi)力，特別是IOS應(yīng)用還要經(jīng)過(guò)Apple審核，

另外，當(dāng)前IOS開(kāi)發(fā)人員、Android開(kāi)發(fā)人員的人工成本普遍較高，人才緊缺，

基于這兩點(diǎn)，能在服務(wù)器端實(shí)現(xiàn)的功能就不要放在客戶端，畢竟服務(wù)器端程序的修改要比客戶端方便、靈活、快捷的多。

8、隱式用戶與顯式用戶

顯式用戶和隱式用戶，我不知道這兩個(gè)詞用的是否確切。

顯式用戶指的是，APP程序中有用戶系統(tǒng)，一個(gè)username、password正確的合法用戶，稱之為顯式的用戶，

通常顯式用戶都需要注冊(cè)，登錄以后能完成一些個(gè)人相關(guān)的操作。

隱式用戶指的是，APP程序本身就沒(méi)有用戶系統(tǒng)，或者一個(gè)在沒(méi)有登錄的情況下，使用我們APP的用戶。

在這種情況下，可以通過(guò)客戶端生成的UDID來(lái)標(biāo)識(shí)一個(gè)用戶。

有了用戶信息，我們就能夠了解不同用戶的使用習(xí)慣，而不僅僅是全體用戶的一個(gè)整體的統(tǒng)計(jì)信息，

有了這些個(gè)體的信息之后，就可以做一些用戶分群、個(gè)性化推薦之類(lèi)的事情。

9、安全問(wèn)題

網(wǎng)絡(luò)安全已經(jīng)從桌面互聯(lián)網(wǎng)轉(zhuǎn)到了移動(dòng)互聯(lián)網(wǎng)，從客戶端蔓延到了接口API中。

傳統(tǒng)固若金湯的網(wǎng)站，很可能因?yàn)榻涌诘囊稽c(diǎn)疏忽而遭受入侵?，F(xiàn)在，在很多白帽子或者黑客的入侵思路中，

先看看移動(dòng)端接口是否存在漏洞，再看網(wǎng)站是否有漏洞。

客戶端APP與接口的通信很容易被得到，只要在中間路由上嗅探一下就行，

whireshark、tcpdump這類(lèi)工具使得這項(xiàng)工作變得簡(jiǎn)單無(wú)比。

所以，接口的安全工作不能馬虎，暴力破解啊、SQL Injection啊、偽造請(qǐng)求和數(shù)據(jù)啊、重復(fù)提交啊也要考慮到,

如果數(shù)據(jù)特別敏感，可以考慮采用SSL/TLS等加密傳輸，或者客戶端、服務(wù)器端約定一個(gè)加密算法和密鑰，對(duì)來(lái)往傳輸?shù)臄?shù)據(jù)進(jìn)行加密、解密

如果不采用RESTful API，可以采用基于WSDL和SOAP的Web Service的安全措施。

10、良好的接口說(shuō)明文檔和測(cè)試程序

接口文檔有時(shí)候是項(xiàng)目初期就定下來(lái)的，前后端開(kāi)發(fā)人員按照接口規(guī)范開(kāi)發(fā)，
有的是接口開(kāi)發(fā)完成后寫(xiě)的。
接口文檔要清晰、明了，包含多少個(gè)接口，每個(gè)接口的地址、參數(shù)、請(qǐng)求方式、數(shù)據(jù)交換格式、返回值等都要寫(xiě)清楚。

接口測(cè)試程序，有條件的話，也可以提供，方便前后端的調(diào)試。

[圖片上傳失敗...(image-1fe259-1510071122729)]

11、版本的維護(hù)

隨著業(yè)務(wù)的變化，客戶端APP和服務(wù)器端API都會(huì)發(fā)生變化，增加新的功能，修改已有的功能，

增加功能還好說(shuō)， 如果是接口需要修改，那么就面臨著同一個(gè)接口要同時(shí)為不同版本的客戶端服務(wù)的問(wèn)題。

因此，服務(wù)器端接口也要做好相應(yīng)的版本維護(hù)。