2014年，移動APP的熱度絲毫沒有減退，怎樣爲您的移動端app設計良好的服務器端接口（API）呢？ 下面談談我個人的一些想法。
2014年，移動APP的熱度絲毫沒有減退，並沒有像桌面軟件被WEB網站那樣所取代，
不但如此，越來越多的傳統應用、網站也都開始製作自己的移動APP，也就是我們常說的IOS客戶端、android客戶端。
這彷彿又回到了多年前的CS架構，那時候我們用VB、VC、Delphi在Windows平臺上快速開發各種應用程序。
不同的是，如今的移動端APP基本上都是聯網從服務器端獲取各種數據，客戶端只是一個簡單的表現層的工具。
不僅僅是移動APP，包括面向服務的SOA架構，都需要制定一套統一、規範的接口，
那麼，做這樣的後端接口需要注意哪些問題呢？
[b]1、跨平臺性[/b]
所謂跨平臺是指我們的接口要能夠支持不同的終端，比如android、ios、windowsphone以及桌面軟件、網站等，
一套接口，支持多端，就像當年Java的口號一樣“Write Once,Run Anywhere”。
當然從本質上講，服務器端的接口跟終端是沒有太大關係的，只是接口應該考慮到不同端的接入成本，
採用通用的解決方案，比如通信協議就採用最常用的HTTP協議，如果是即時通信，可以採用開放的XMPP協議，
做遊戲的可以採用可靠的TCP協議，除非TCP不夠用了，再採用定製的UDP協議。
數據交換採用xml或者json格式等等。
總之，要達到的目標就是讓不同的端能夠很方便的使用你的接口。
[b]2、良好的響應速度[/b]
如果要用一個指標來衡量接口的性能的話，那麼我想最重要的就是響應速度了。
接口應該以最快的速度將數據返回給請求者。
試想，當我們打開一個頁面，如果“努力加載中”之類的提示超過三五秒鐘的話，
我們肯定會變得不耐煩，移動app本來大部分就是用戶在碎片化時間來使用的，
在有限的時間內，用戶恨不得獲得的信息越多越好，即使你的app界面設計的再好，用戶也不會買賬。
提高響應速度又是個老生常談的問題，大體上應該按照以下步驟來做：
初期，以功能爲主，要保證功能完整，滿足業務需求，這階段可以使用動態的語言，比如java、php、asp.net等，
配合設計良好的數據庫結構和索引，能滿足一定的需求；
其次，隨着用戶的增多，可以考慮一些緩存方案，緩存是解決性能問題的萬金油，通常能起到立竿見影的效果。
最常用的靜態文件緩存，memcached內存緩存等。
然後，單臺機器的吞吐率不行了，通過負載均衡多加幾臺機器就行了。七八臺機器，支持每天千萬級的接口調用是可行的。
或者，直接採用CDN的解決方案，將絕大多數的靜態資源交給CDN去處理。
總之，要達到的目標就是快，一個頁面，秒開最好，超過三秒就需要找找原因了。
[b]3、接口要爲移動客戶端考慮[/b]
接口不僅僅是提供數據和功能就完事了，更應該充分考慮移動端的特性，爲移動端提供更加方便、快捷的接口。
比如，在移動端裏，下拉刷新和上拉加載更多是很常見的功能，如果接口仍然按照傳統的web思路，
只提供按頁讀取的話，就會造成移動端的額外的數據請求和計算。 這時，接口就應該針對這兩種類型的操作提供額外的支持。
再比如，對於一個新聞閱讀類的app來說，最新的新聞列表裏的文章，特別是前幾條，用戶很容易點擊進去看，
而後面的老的文章列表，一來用戶下滑加載好幾頁的情況較少，二來過時的新聞用戶也很少點。
如果，接口在返回新聞列表時，對於最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的內容）信息一起傳給客戶端，
這樣，用戶在打開新聞詳情頁的時候，就不用再從服務器端獲取了，自然可以做到秒開。
比如訪問第一頁時，接口可以返回文章內容，如下所示 ，content=1表示加載文章內容
newslist?page=1&pagesize=20&content=1
其他頁時，newslist?page=5&pagesize=20&content=0 ,不用加載文章內容。
當然，客戶端要跟接口做好配合，搭配好，才能最大化的提高性能。
比如，移動端都有左右滑動來看上一篇、下一篇文章或者圖片的功能，
如果，當用戶請求某篇文章的時候，服務器端順便也把下一篇文章的內容返回回來了，
那麼當用戶看下一篇的時候，是不是就很快了呢。
當然這種preload的方案也不能濫用，如果預加載數據的命中率較低的話，也不行，白白浪費了很多的流量。
[b]4、考慮移動端的網絡情況和耗電量[/b]
如果讓我們說出哪類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有大量的計算、有很炫的視覺畫面都會消耗電量， 另外，不斷的移動網絡鏈接也會消耗大量的電量，
我們都知道移動網絡是通過無線電波來通訊的，那麼發射裝置就需要消耗一定的電量來發射和接收無線信號。
特別的是，頻繁的鏈接會不斷的切換網絡設備與移動基站之間連接狀態，這都會消耗一部分電量。
所以，對於接口而言，儘量用少的鏈接傳輸多的數據，
比如，對於關於我們、版本更新以及一些系統配置信息，完全可以通過一次鏈接全部返回給客戶端。
[b]5、通用的數據交換格式[/b]
目前，對於接口和客戶端的數據交換格式，基本上就是兩種，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'
}
[b]6、接口統計功能[/b]
在做PC端網站的時候，我們都會給我們的網站加上個統計功能，要麼自己寫統計系統，要麼使用第三方的比如GA、百度等。
移動端接口API則需要我們自己實現統計功能，
這時就需要我們儘可能多的收集客戶端的信息，除了傳統的IP、User-Agent之外，還應該收集一些移動相關的信息，
比如
手機操作系統，是android還是ios，都是什麼版本，
用戶使用的網絡狀況，是2G、3G、4G還是WIFI
客戶端APP是什麼版本信息。
這樣，有助於我們更好的瞭解我們用戶的使用情況。
[b]7、客戶端與服務端的肥瘦平衡[/b]
在以前C/S、B/S架構時，我們就已多次討論過這個問題，客戶端是瘦點好還是肥點好，當然也沒有固定答案，需要自己根據實際情況去做權衡。
但是，在移動開發中，由於客戶端的修改會很費時費力，特別是IOS應用還要經過Apple審覈，
另外，當前IOS開發人員、Android開發人員的人工成本普遍較高，人才緊缺，
基於這兩點，能在服務器端實現的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。
[b]8、隱式用戶與顯式用戶[/b]
顯式用戶和隱式用戶，我不知道這兩個詞用的是否確切。
顯式用戶指的是，APP程序中有用戶系統，一個username、password正確的合法用戶，稱之爲顯式的用戶，
通常顯式用戶都需要註冊，登錄以後能完成一些個人相關的操作。
隱式用戶指的是，APP程序本身就沒有用戶系統，或者一個在沒有登錄的情況下，使用我們APP的用戶。
在這種情況下，可以通過客戶端生成的UDID來標識一個用戶。
有了用戶信息，我們就能夠了解不同用戶的使用習慣，而不僅僅是全體用戶的一個整體的統計信息，
有了這些個體的信息之後，就可以做一些用戶分羣、個性化推薦之類的事情。
[b]9、安全問題 [/b]
網絡安全已經從桌面互聯網轉到了移動互聯網，從客戶端蔓延到了接口API中。
傳統固若金湯的網站，很可能因爲接口的一點疏忽而遭受入侵。現在，在很多白帽子或者黑客的入侵思路中，
先看看移動端接口是否存在漏洞，再看網站是否有漏洞。
客戶端APP與接口的通信很容易被得到，只要在中間路由上嗅探一下就行，
whireshark、tcpdump這類工具使得這項工作變得簡單無比。
所以，接口的安全工作不能馬虎，暴力破解啊、SQL Injection啊、僞造請求和數據啊、重複提交啊也要考慮到,
如果數據特別敏感，可以考慮採用SSL/TLS等加密傳輸，或者客戶端、服務器端約定一個加密算法和密鑰，對來往傳輸的數據進行加密、解密
如果不採用RESTful API，可以採用基於WSDL和SOAP的Web Service的安全措施。
[b]10、良好的接口說明文檔和測試程序[/b]
接口文檔有時候是項目初期就定下來的，前後端開發人員按照接口規範開發，
有的是接口開發完成後寫的。
接口文檔要清晰、明瞭，包含多少個接口，每個接口的地址、參數、請求方式、數據交換格式、返回值等都要寫清楚。
接口測試程序，有條件的話，也可以提供，方便前後端的調試。
[img]http://www.hutuseng.com/uploads/attached/image/20140412/20140412113958_85616.jpg[/img]
[b]11、版本的維護[/b]
隨着業務的變化，客戶端APP和服務器端API都會發生變化，增加新的功能，修改已有的功能，
增加功能還好說， 如果是接口需要修改，那麼就面臨着同一個接口要同時爲不同版本的客戶端服務的問題。
因此，服務器端接口也要做好相應的版本維護。
2014年，移動APP的熱度絲毫沒有減退，並沒有像桌面軟件被WEB網站那樣所取代，
不但如此，越來越多的傳統應用、網站也都開始製作自己的移動APP，也就是我們常說的IOS客戶端、android客戶端。
這彷彿又回到了多年前的CS架構，那時候我們用VB、VC、Delphi在Windows平臺上快速開發各種應用程序。
不同的是，如今的移動端APP基本上都是聯網從服務器端獲取各種數據，客戶端只是一個簡單的表現層的工具。
不僅僅是移動APP，包括面向服務的SOA架構，都需要制定一套統一、規範的接口，
那麼，做這樣的後端接口需要注意哪些問題呢？
[b]1、跨平臺性[/b]
所謂跨平臺是指我們的接口要能夠支持不同的終端，比如android、ios、windowsphone以及桌面軟件、網站等，
一套接口，支持多端，就像當年Java的口號一樣“Write Once,Run Anywhere”。
當然從本質上講，服務器端的接口跟終端是沒有太大關係的，只是接口應該考慮到不同端的接入成本，
採用通用的解決方案，比如通信協議就採用最常用的HTTP協議，如果是即時通信，可以採用開放的XMPP協議，
做遊戲的可以採用可靠的TCP協議，除非TCP不夠用了，再採用定製的UDP協議。
數據交換採用xml或者json格式等等。
總之，要達到的目標就是讓不同的端能夠很方便的使用你的接口。
[b]2、良好的響應速度[/b]
如果要用一個指標來衡量接口的性能的話，那麼我想最重要的就是響應速度了。
接口應該以最快的速度將數據返回給請求者。
試想，當我們打開一個頁面，如果“努力加載中”之類的提示超過三五秒鐘的話，
我們肯定會變得不耐煩，移動app本來大部分就是用戶在碎片化時間來使用的，
在有限的時間內，用戶恨不得獲得的信息越多越好，即使你的app界面設計的再好，用戶也不會買賬。
提高響應速度又是個老生常談的問題，大體上應該按照以下步驟來做：
初期，以功能爲主，要保證功能完整，滿足業務需求，這階段可以使用動態的語言，比如java、php、asp.net等，
配合設計良好的數據庫結構和索引，能滿足一定的需求；
其次，隨着用戶的增多，可以考慮一些緩存方案，緩存是解決性能問題的萬金油，通常能起到立竿見影的效果。
最常用的靜態文件緩存，memcached內存緩存等。
然後，單臺機器的吞吐率不行了，通過負載均衡多加幾臺機器就行了。七八臺機器，支持每天千萬級的接口調用是可行的。
或者，直接採用CDN的解決方案，將絕大多數的靜態資源交給CDN去處理。
總之，要達到的目標就是快，一個頁面，秒開最好，超過三秒就需要找找原因了。
[b]3、接口要爲移動客戶端考慮[/b]
接口不僅僅是提供數據和功能就完事了，更應該充分考慮移動端的特性，爲移動端提供更加方便、快捷的接口。
比如，在移動端裏，下拉刷新和上拉加載更多是很常見的功能，如果接口仍然按照傳統的web思路，
只提供按頁讀取的話，就會造成移動端的額外的數據請求和計算。 這時，接口就應該針對這兩種類型的操作提供額外的支持。
再比如，對於一個新聞閱讀類的app來說，最新的新聞列表裏的文章，特別是前幾條，用戶很容易點擊進去看，
而後面的老的文章列表，一來用戶下滑加載好幾頁的情況較少，二來過時的新聞用戶也很少點。
如果，接口在返回新聞列表時，對於最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的內容）信息一起傳給客戶端，
這樣，用戶在打開新聞詳情頁的時候，就不用再從服務器端獲取了，自然可以做到秒開。
比如訪問第一頁時，接口可以返回文章內容，如下所示 ，content=1表示加載文章內容
newslist?page=1&pagesize=20&content=1
其他頁時，newslist?page=5&pagesize=20&content=0 ,不用加載文章內容。
當然，客戶端要跟接口做好配合，搭配好，才能最大化的提高性能。
比如，移動端都有左右滑動來看上一篇、下一篇文章或者圖片的功能，
如果，當用戶請求某篇文章的時候，服務器端順便也把下一篇文章的內容返回回來了，
那麼當用戶看下一篇的時候，是不是就很快了呢。
當然這種preload的方案也不能濫用，如果預加載數據的命中率較低的話，也不行，白白浪費了很多的流量。
[b]4、考慮移動端的網絡情況和耗電量[/b]
如果讓我們說出哪類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有大量的計算、有很炫的視覺畫面都會消耗電量， 另外，不斷的移動網絡鏈接也會消耗大量的電量，
我們都知道移動網絡是通過無線電波來通訊的，那麼發射裝置就需要消耗一定的電量來發射和接收無線信號。
特別的是，頻繁的鏈接會不斷的切換網絡設備與移動基站之間連接狀態，這都會消耗一部分電量。
所以，對於接口而言，儘量用少的鏈接傳輸多的數據，
比如，對於關於我們、版本更新以及一些系統配置信息，完全可以通過一次鏈接全部返回給客戶端。
[b]5、通用的數據交換格式[/b]
目前，對於接口和客戶端的數據交換格式，基本上就是兩種，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'
}
[b]6、接口統計功能[/b]
在做PC端網站的時候，我們都會給我們的網站加上個統計功能，要麼自己寫統計系統，要麼使用第三方的比如GA、百度等。
移動端接口API則需要我們自己實現統計功能，
這時就需要我們儘可能多的收集客戶端的信息，除了傳統的IP、User-Agent之外，還應該收集一些移動相關的信息，
比如
手機操作系統，是android還是ios，都是什麼版本，
用戶使用的網絡狀況，是2G、3G、4G還是WIFI
客戶端APP是什麼版本信息。
這樣，有助於我們更好的瞭解我們用戶的使用情況。
[b]7、客戶端與服務端的肥瘦平衡[/b]
在以前C/S、B/S架構時，我們就已多次討論過這個問題，客戶端是瘦點好還是肥點好，當然也沒有固定答案，需要自己根據實際情況去做權衡。
但是，在移動開發中，由於客戶端的修改會很費時費力，特別是IOS應用還要經過Apple審覈，
另外，當前IOS開發人員、Android開發人員的人工成本普遍較高，人才緊缺，
基於這兩點，能在服務器端實現的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。
[b]8、隱式用戶與顯式用戶[/b]
顯式用戶和隱式用戶，我不知道這兩個詞用的是否確切。
顯式用戶指的是，APP程序中有用戶系統，一個username、password正確的合法用戶，稱之爲顯式的用戶，
通常顯式用戶都需要註冊，登錄以後能完成一些個人相關的操作。
隱式用戶指的是，APP程序本身就沒有用戶系統，或者一個在沒有登錄的情況下，使用我們APP的用戶。
在這種情況下，可以通過客戶端生成的UDID來標識一個用戶。
有了用戶信息，我們就能夠了解不同用戶的使用習慣，而不僅僅是全體用戶的一個整體的統計信息，
有了這些個體的信息之後，就可以做一些用戶分羣、個性化推薦之類的事情。
[b]9、安全問題 [/b]
網絡安全已經從桌面互聯網轉到了移動互聯網，從客戶端蔓延到了接口API中。
傳統固若金湯的網站，很可能因爲接口的一點疏忽而遭受入侵。現在，在很多白帽子或者黑客的入侵思路中，
先看看移動端接口是否存在漏洞，再看網站是否有漏洞。
客戶端APP與接口的通信很容易被得到，只要在中間路由上嗅探一下就行，
whireshark、tcpdump這類工具使得這項工作變得簡單無比。
所以，接口的安全工作不能馬虎，暴力破解啊、SQL Injection啊、僞造請求和數據啊、重複提交啊也要考慮到,
如果數據特別敏感，可以考慮採用SSL/TLS等加密傳輸，或者客戶端、服務器端約定一個加密算法和密鑰，對來往傳輸的數據進行加密、解密
如果不採用RESTful API，可以採用基於WSDL和SOAP的Web Service的安全措施。
[b]10、良好的接口說明文檔和測試程序[/b]
接口文檔有時候是項目初期就定下來的，前後端開發人員按照接口規範開發，
有的是接口開發完成後寫的。
接口文檔要清晰、明瞭，包含多少個接口，每個接口的地址、參數、請求方式、數據交換格式、返回值等都要寫清楚。
接口測試程序，有條件的話，也可以提供，方便前後端的調試。
[img]http://www.hutuseng.com/uploads/attached/image/20140412/20140412113958_85616.jpg[/img]
[b]11、版本的維護[/b]
隨着業務的變化，客戶端APP和服務器端API都會發生變化，增加新的功能，修改已有的功能，
增加功能還好說， 如果是接口需要修改，那麼就面臨着同一個接口要同時爲不同版本的客戶端服務的問題。
因此，服務器端接口也要做好相應的版本維護。
