通訊協議

一些只是對伺服器資料進行CRUD操作的App，通常採用HTTP協議，為了安全也可以採用HTTPS協議。IM軟體可以選擇使用XMPP協議。

其他一些特有場景的App可能基於Socket自定義協議。

SOCKET是實現傳輸層協議的一種程式設計API，可以是TCP，也可以是UDP。

TCP --- 傳輸控制協議,提供的是面向連線、可靠的位元組流服務。TCP提供超時重發，丟棄重複資料，檢驗資料，流量控制等功能，保證資料能從一端傳到另一端。

UDP --- 使用者資料報協議，是一個無連線的簡單的面向資料報的運輸層協議。UDP不提供可靠性，它只是把應用程式傳給IP層的資料報傳送出去，但是並不能保證它們能到達目的地。

在需要保證需要傳輸資料到對方的時候應該選擇TCP協議，比如檔案傳輸。而像線上視訊播放這些，可以不用保證資料100%被接受的，可以用UDP，因為丟失一幀畫面資料沒什麼影響，而且用UDP速度會更快。

最近也有聽說用WebSocket做通訊的，可以在Web端和App端共用一個介面。

資料格式

比較通用的資料互動格式是JSON和XML。在現在，JSON格式使用的更為廣泛，因為結構簡單而且解析方便。

iOS5之後的SDK提供了NSJSONSerialization類解析JSON，而Android SDK本身就自帶了org.json 的相關包來提供JSON解析的功能。如果在Android裡面對JSON的解析或者序列化效能有要求，可以考慮使用android.utils包裡面的JsonReader 和  JsonWriter類。它們是用流式解析的方式，不過使用更加繁瑣。也可以考慮使用Google的Gson，阿里巴巴的fastjson，以及Jackson這些開源JSON處理的庫，它們提供了更多的功能，也有更好的效能。

XML設計目標是“Extensible Markup Language”，可擴充套件的標記語言，而不是JSON的只是作為一個數據序列化的語言。XML格式也有自己的優點，比如你可以用通用的XPath查詢特定的資料而不用用一個個巢狀的迴圈或者分支語句從一個複雜的資料中拿到一個特定的值。

REST架構的API設計

本文其餘內容基本都是在談REST架構的API

一些感想:

1. API請求中應該加入API版本號，比如在URL中加入版本號，如
   https://api.example.com/v1/， 這樣當API升級的或者改動的時候，可以保留舊的API伺服器，把新的API伺服器mount到https://api.example.com/v2/
   上，這樣使用舊的API的App也不會出現問題
2. API返回的資料量小的時候，沒太多必要進行zip壓縮。API返回資料大的時候，要考慮API設計是否適當。
   4.寫API要方便使用這些API開發的人員測試，比如寫好文件，使用https://helloreverb.com/developers/swagger  這樣的工具生成除錯頁面。

效能

要避免寫API Server的時候出現一些低階的錯誤，比如資料庫查詢用了N＋1 Query。

其他效能的問題其實和Web開發大同小異，無非是橫向和縱向的幾種不同方式的擴充套件。

安全性和使用者認證

如果使用第三方的API，通常採用Oauth協議或者SSO登入。

如果是自己開發，因為自己寫HTTP請求不會和瀏覽器傳送的時候自動維護一個Cookie，所以可以自己手動維護一個Token，代替Cookie的作用來進行使用者驗證。

對於Token等關鍵的資料，不要明文儲存在裝置本地，可以用iOS提供的Keychain這樣的機制進行加密儲存。

也有用Xauth協議的，類似Oauth的簡化版。

安全方便，和Web開發一樣，不要相信使用者的任何資料，伺服器端都應該做對應的認證。

此外，如果對一些資料有較高的安全需求，那麼應該避免把祕密的資料用明文寫在程式碼裡，比如一些第三方Acess Key，可以在啟動的時候動態請求，否則很容易被反編譯獲取。

Android一定要做好反編譯工作。

學習

此外，可以用Charles這些抓包工具，學習和參考別人的App與伺服器的資料互動內容，Charles甚至可以在你的開發的移動裝置上安裝自簽名證書，採用類似中間人攻擊的方式來獲取App採用HTTPS協議互動的資料的明文。

如果你不想寫API

你可以使用Parse.com 或者 AVOSCloud 這些BASS平臺提供的服務。這些服務很適合一些不需要在伺服器端提供複雜操作，以及前期的原型開發。