app與後台通訊協定

標籤：個人   失敗   推送   模型   資源   推薦   網站   服務端   問題   

　通用的語言有很多種，例如英語和中文，在網路的通訊中，通用的協議有很多，其中http是被最廣泛使用的。如果是私人的協議，那就只能自己設計了。

　　用http是最方便的，如果是私人協議，包含協議的封裝和拆解，工作量大，前端程式員和後端程式員都要增加很多額外的工作量。而且私人協議對程式員的要求高，不適合從web網站轉過來的開發人員。除非是手遊，不然用http就好了。

（2）app和伺服器通訊使用長串連還是短串連？

　　假設現在通過手機撥打另外一個人的手機，手機通話費用非常便宜（甚至可以忽略），但是有兩個注意的地方：

　　1.一台手機同一時間只能接聽一個電話。

　　2.一台手機電話中前非常麻煩，要撥號啦，要等接聽，這需要一段時間。

　　app和伺服器通訊使用長串連還是短串連這個問題，可以等同於上面電話模型，是一直保持著通話，還是有需要時才撥號通話這個問題？

2）app和伺服器通訊使用長串連還是短串連？

　　假設現在通過手機撥打另外一個人的手機，手機通話費用非常便宜（甚至可以忽略），但是有兩個注意的地方：

　　1.一台手機同一時間只能接聽一個電話。

　　2.一台手機電話中前非常麻煩，要撥號啦，要等接聽，這需要一段時間。

　　app和伺服器通訊使用長串連還是短串連這個問題，可以等同於上面電話模型，是一直保持著通話，還是有需要時才撥號通話這個問題？

　　當app和伺服器通訊使用長串連，就相當於一直保持著通話，伺服器能保持的通訊數量有限，如果通訊滿了，那其他app就不能和服務端通訊了。這種通訊方式，多數是使用socket或websocket串連長時間串連，對程式員的要求比較高，開發比較困難，除了手遊和聊天推送服務外，不建議使用。

　　當app和伺服器通訊使用短串連，就相當於需要時才撥號通話。這種通訊方式，配合http協議，是現在主流的通訊方式，開發效率高，有大量的第三方資源，使用非常廣泛，推薦使用這種方式。

當app調用api的時候，只需要明確下面３點:

　　1.這個api是幹啥的（櫃員機例子中，是取款功能，還是查詢餘額,還是轉賬）

　　2.知道要輸入什麼（櫃員機例子中，取款要輸入金錢）

　　3.知道結果是什麼（櫃員機例子中，取款是成功還是失敗）

　　至於api內部是怎麼處理的，app根本無需理會。

　　api，一般是以http的形式調用的，通過http傳入參數，返回結果。其中，結果一般是以json格式返回的，因為json格式被眾多電腦語言支援，而且省流量。

app與後台通訊協定