2014.9.8更新：
最近有一篇關(guān)于HTTP API設(shè)計的文章值得參考：https://github.com/interagent/http-api-design，中文翻譯：https://github.com/cocoajin/http-api-design-ZH_CN
通訊協(xié)議
一些只是對服務(wù)器數(shù)據(jù)進(jìn)行CRUD操作的App，通常采用HTTP協(xié)議，為了安全也可以采用HTTPS協(xié)議。IM軟件可以選擇使用XMPP協(xié)議。
其他一些特有場景的App可能基于Socket自定義協(xié)議。
SOCKET是實現(xiàn)傳輸層協(xié)議的一種編程API，可以是TCP，也可以是UDP。
TCP --- 傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務(wù)。TCP提供超時重發(fā)，丟棄重復(fù)數(shù)據(jù)，檢驗數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端。
UDP --- 用戶數(shù)據(jù)報協(xié)議，是一個無連接的簡單的面向數(shù)據(jù)報的運輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報發(fā)送出去，但是并不能保證它們能到達(dá)目的地。
在需要保證需要傳輸數(shù)據(jù)到對方的時候應(yīng)該選擇TCP協(xié)議，比如文件傳輸。而像在線視頻播放這些，可以不用保證數(shù)據(jù)100%被接受的，可以用UDP，因為丟失一幀畫面數(shù)據(jù)沒什么影響，而且用UDP速度會更快。
最近也有聽說用WebSocket做通訊的，可以在Web端和App端共用一個接口。
數(shù)據(jù)格式
比較通用的數(shù)據(jù)交互格式是JSON和XML。在現(xiàn)在，JSON格式使用的更為廣泛，因為結(jié)構(gòu)簡單而且解析方便。
iOS5之后的SDK提供了NSJSONSerialization類解析JSON，而Android SDK本身就自帶了org.json 的相關(guān)包來提供JSON解析的功能。如果在Android里面對JSON的解析或者序列化性能有要求，可以考慮使用android.utils包里面的JsonReader 和 JsonWriter類。它們是用流式解析的方式，不過使用更加繁瑣。也可以考慮使用Google的Gson，阿里巴巴的fastjson，以及Jackson這些開源JSON處理的庫，它們提供了更多的功能，也有更好的性能。
XML設(shè)計目標(biāo)是“Extensible Markup Language”，可擴展的標(biāo)記語言，而不是JSON的只是作為一個數(shù)據(jù)序列化的語言。XML格式也有自己的優(yōu)點，比如你可以用通用的XPath查詢特定的數(shù)據(jù)而不用用一個個嵌套的循環(huán)或者分支語句從一個復(fù)雜的數(shù)據(jù)中拿到一個特定的值。
REST架構(gòu)的API設(shè)計
可以參考阮一峰文章http://www.ruanyifeng.com/blog/2014/05/restful_api.html
本文其余內(nèi)容基本都是在談REST架構(gòu)的API
一些感想:
- API域名與網(wǎng)站域名分開，比如使用 https://api.example.com 這樣的方式
- API請求中應(yīng)該加入API版本號，比如在URL中加入版本號，如
https://api.example.com/v1/， 這樣當(dāng)API升級的或者改動的時候，可以保留舊的API服務(wù)器，把新的API服務(wù)器mount到https://api.example.com/v2/ 上，這樣使用舊的API的App也不會出現(xiàn)問題 - API返回的數(shù)據(jù)量小的時候，沒太多必要進(jìn)行zip壓縮。API返回數(shù)據(jù)大的時候，要考慮API設(shè)計是否適當(dāng)。
4.寫API要方便使用這些API開發(fā)的人員測試，比如寫好文檔，使用https://helloreverb.com/developers/swagger 這樣的工具生成調(diào)試頁面。
性能
要避免寫API Server的時候出現(xiàn)一些低級的錯誤，比如數(shù)據(jù)庫查詢用了N＋1 Query。
其他性能的問題其實和Web開發(fā)大同小異，無非是橫向和縱向的幾種不同方式的擴展。
安全性和用戶認(rèn)證
如果使用第三方的API，通常采用Oauth協(xié)議或者SSO登錄。
如果是自己開發(fā)，因為自己寫HTTP請求不會和瀏覽器發(fā)送的時候自動維護(hù)一個Cookie，所以可以自己手動維護(hù)一個Token，代替Cookie的作用來進(jìn)行用戶驗證。
對于Token等關(guān)鍵的數(shù)據(jù)，不要明文保存在設(shè)備本地，可以用iOS提供的Keychain這樣的機制進(jìn)行加密存儲。
也有用Xauth協(xié)議的，類似Oauth的簡化版。
安全方便，和Web開發(fā)一樣，不要相信用戶的任何數(shù)據(jù)，服務(wù)器端都應(yīng)該做對應(yīng)的認(rèn)證。
此外，如果對一些數(shù)據(jù)有較高的安全需求，那么應(yīng)該避免把秘密的數(shù)據(jù)用明文寫在代碼里，比如一些第三方Acess Key，可以在啟動的時候動態(tài)請求，否則很容易被反編譯獲取。
Android一定要做好反編譯工作。
學(xué)習(xí)
Github的API設(shè)計應(yīng)該算得上優(yōu)秀，值得參考：
https://developer.github.com/v3/
此外，可以用Charles這些抓包工具，學(xué)習(xí)和參考別人的App與服務(wù)器的數(shù)據(jù)交互內(nèi)容，Charles甚至可以在你的開發(fā)的移動設(shè)備上安裝自簽名證書，采用類似中間人攻擊的方式來獲取App采用HTTPS協(xié)議交互的數(shù)據(jù)的明文。
如果你不想寫API
你可以使用Parse.com 或者 AVOSCloud 這些BASS平臺提供的服務(wù)。這些服務(wù)很適合一些不需要在服務(wù)器端提供復(fù)雜操作，以及前期的原型開發(fā)。
