App架構設計經驗談:介面的設計
轉自: http://keeganlee.me/post/architecture/20160107
App與伺服器的通訊介面如何設計得好,需要考慮的地方挺多的,在此根據我的一些經驗做一些總結分享,旨在拋磚引玉。
安全機制的設計
現在,大部分App的介面都採用RESTful架構,RESTFul最重要的一個設計原則就是,客戶端與伺服器的互動在請求之間是無狀態的,也就是說,當涉及到使用者狀態時,每次請求都要帶上身份驗證資訊。實現上,大部分都採用token的認證方式,一般流程是:
- 使用者用密碼登入成功後,伺服器返回token給客戶端;
- 客戶端將token儲存在本地,發起後續的相關請求時,將token發回給伺服器;
- 伺服器檢查token的有效性,有效則返回資料,若無效,分兩種情況:
- token錯誤,這時需要使用者重新登入,獲取正確的token
- token過期,這時客戶端需要再發起一次認證請求,獲取新的token
然而,此種驗證方式存在一個安全性問題:當登入介面被劫持時,黑客就獲取到了使用者密碼和token,後續則可以對該使用者做任何事情了。使用者只有修改密碼才能奪回控制權。
如何優化呢?第一種解決方案是採用HTTPS。HTTPS在HTTP的基礎上添加了SSL安全協議,自動對資料進行了壓縮加密,在一定程式可以防止監聽、防止劫持、防止重發,安全性可以提高很多。不過,SSL也不是絕對安全的,也存在被劫持的可能。另外,伺服器對HTTPS的配置相對有點複雜,還需要到CA申請證書,而且一般還是收費的。而且,HTTPS效率也比較低。一般,只有安全要求比較高的系統才會採用HTTPS,比如銀行。而大部分對安全要求沒那麼高的App還是採用HTTP的方式。
我們目前的做法是給每個介面都添加簽名。給客戶端分配一個金鑰,每次請求介面時,將金鑰和所有引數組合成源串,根據簽名演算法生成簽名值,傳送請求時將簽名一起傳送給伺服器驗證。類似的實現可參考OAuth1.0的簽名演算法。這樣,黑客不知道金鑰,不知道簽名演算法,就算攔截到登入介面,後續請求也無法成功操作。不過,因為簽名演算法比較麻煩,而且容易出錯,只適合對內的介面。如果你們的介面屬於開放的API,則不太適合這種簽名認證的方式了,建議還是使用OAuth2.0的認證機制。
我們也給每個端分配一個appKey,比如Android、iOS、微信三端,每個端分別分配一個appKey和一個金鑰。沒有傳appKey的請求將報錯,傳錯了appKey的請求也將報錯。這樣,安全性方面又加多了一層防禦,同時也方便對不同端做一些不同的處理策略。
另外,現在越來越多App取消了密碼登入,而採用手機號+簡訊驗證碼的登入方式,我在當前的專案中也採用了這種登入方式。這種登入方式有幾種好處:
- 不需要註冊,不需要修改密碼,也不需要因為忘記密碼而重置密碼的操作了;
- 使用者不再需要記住密碼了,也不怕密碼洩露的問題了;
- 相對於密碼登入其安全性明顯提高了。
介面資料的設計
介面的資料一般都採用JSON格式進行傳輸,不過,需要注意的是,JSON的值只有六種資料型別:
- Number:整數或浮點數
- String:字串
- Boolean:true 或 false
- Array:陣列包含著方括號[]中
- Object:物件包含在大括號{}中
- Null:空型別
所以,傳輸的資料型別不能超過這六種資料型別。以前,我們曾經試過傳輸Date型別,它會轉為類似於"2016年1月7日 09時17分42秒 GMT+08:00"這樣的字串,這在轉換時會產生問題,不同的解析庫解析方式可能不同,有的可能會轉亂,有的可能直接異常了。要避免出錯,必須做特殊處理,自己手動去做解析。為了根除這種問題,最好的解決方案是用毫秒數表示日期。
另外,以前的專案中還出現過字串的"true"和"false",或者字串的數字,甚至還出現過字串的"null",導致解析錯誤,尤其是"null",導致App奔潰,後來查了好久才查出來是該問題導致的。這都是因為服務端對資料沒處理好,導致有些資料轉為了字串。所以,在客戶端,也不能完全信任服務端傳回的資料都是對的,需要對所有異常情況都做相應處理。
伺服器返回的資料結構,一般為:
{ code:0 message: "success" data: { key1: value1, key2: value2, ... } }
- code: 狀態碼,0表示成功,非0表示各種不同的錯誤
- message: 描述資訊,成功時為"success",錯誤時則是錯誤資訊
- data: 成功時返回的資料,型別為物件或資料
不同錯誤需要定義不同的狀態碼,屬於客戶端的錯誤和服務端的錯誤也要區分,比如1XX表示客戶端的錯誤,2XX表示服務端的錯誤。這裡舉幾個例子:
- 0:成功
- 100:請求錯誤
- 101:缺少appKey
- 102:缺少簽名
- 103:缺少引數
- 200:伺服器出錯
- 201:服務不可用
- 202:伺服器正在重啟
錯誤資訊一般有兩種用途:一是客戶端開發人員除錯時看具體是什麼錯誤;二是作為App錯誤提示直接展示給使用者看。主要還是作為App錯誤提示,直接展示給使用者看的。所以,大部分都是簡短的提示資訊。
data欄位只在請求成功時才會有資料返回的。資料型別限定為物件或陣列,當請求需要的資料為單個物件時則傳回物件,當請求需要的資料是列表時,則為某個物件的陣列。這裡需要注意的就是,不要將data傳入字串或數字,即使請求需要的資料只有一個,比如token,那返回的data應該為:
// 正確 data: { token: 123456 } // 錯誤 data: 123456
介面版本的設計
介面不可能一成不變,在不停迭代中,總會發生變化。介面的變化一般會有幾種:
- 資料的變化,比如增加了舊版本不支援的資料型別
- 引數的變化,比如新增了引數
- 介面的廢棄,不再使用該介面了
為了適應這些變化,必須得做介面版本的設計。實現上,一般有兩種做法:
- 每個介面有各自的版本,一般為介面添加個version的引數。
- 整個介面系統有統一的版本,一般在URL中新增版本號,比如http://api.domain.com/v2。
大部分情況下會採用第一種方式,當某一個介面有變動時,在這個介面上疊加版本號,併兼容舊版本。App的新版本開發傳參時則將傳入新版本的version。
如果整個介面系統的根基都發生變動的話,比如微博API,從OAuth1.0升級到OAuth2.0,整個API都進行了升級。
有時候,一個介面的變動還會影響到其他介面,但做的時候不一定能發現。因此,最好還要有一套完善的測試機制保證每次介面變更都能測試到所有相關層面。
相關推薦
App架構設計經驗談:介面的設計
轉自: http://keeganlee.me/post/architecture/20160107 App與伺服器的通訊介面如何設計得好,需要考慮的地方挺多的,在此根據我的一些經驗做一些總結分享,旨在拋磚引玉。 安全機制的設計 現在,大部分App的介面都採用RES
前後端分離架構中的介面設計
前後端分離一般是指在軟體開發過程中,前端程式碼和後端程式碼分別開發,互不干涉,不使用後端語言去寫前端,也不用前端技術寫後端,從形式上來說,一般是不用JSP或PHP混寫程式碼,但並不是說不能用JSP或php檔案格式。前後端分離後,前後端的通訊一般是通過HTTP介面的方式進行
App架構設計經驗談:介面的設計
安全機制的設計 現在,大部分App的介面都採用RESTful架構,RESTFul最重要的一個設計原則就是,客戶端與伺服器的互動在請求之間是無狀態的,也就是說,當涉及到使用者狀態時,每次請求都要帶上身份驗證資訊。實現上,大部分都採用token的認證方式,一般流程是:
[轉]App架構設計經驗談:接口的設計
手動 alt obj jpg 檢查 服務器 相對 版本號 單個 原文地址:http://developer.51cto.com/art/201601/503767.htm App與服務器的通信接口如何設計得好,需要考慮的地方挺多的,在此根據我的一些經驗做一些總結分享,旨在拋
App架構設計經驗談:資料層的設計
一個App,從根本上來說,就是對資料的處理,包括資料從哪裡來、資料如何組織、資料怎麼展示,從職責上劃分就是:資料管理、資料加工、資料展示。相對應的也就有了三層架構:資料層、業務層、展示層。本文就先講講資料層的設計。 資料層,是三層架構中的最底層,負責資料的管理。它主要的任務
android app 架構設計01
clas -h tab size data 資源 top post 樣式 1:本文有摘抄, 1 2 3 4 5 - 開發過程中。需求、設計、編碼的一致性 - 整個程序具有統一的風格,比方對話框樣式,button風格,色調等UI元素 - 整個程序詳細統一的結
手機APP介面:設計一個獲取手機驗證碼的功能
現在的專案中,都會涉及到一個手機驗證碼獲取功能 我們今天就來探討下如何更好的設計好這個看似小的功能 給APP設計一個獲取手機驗證碼的介面 根據業務邏輯,初步總結了可能會有以下業務場景 需要用到手機驗證碼的驗證功能 大家來看下圖片吧 login:登入 reg
APP介面設計安全問題
分享一下我老師大神的人工智慧教程吧。零基礎,通俗易懂!風趣幽默!http://www.captainbed.net/ 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!
APP介面設計流程和APP產品設計流程知識彙總
本文轉載自網際網路,如有侵權,請聯絡我及時刪除。謝謝。 第一部分:APP介面設計流程概要分享,總共11個步驟。 1. 確定你的創意方向或者圍繞主題展開 您的創意是否有人做過,如果有類似的app,那就要多多考慮,爭取超越並且有一些獨特的優化設計在其中
App介面設計之token的php實現
App介面設計之token的php實現 為了保證移動端和服務端資料傳輸相對安全,需要對介面進行加密傳輸。 一、token的設計目的: 因為APP端沒有和PC端一樣的session機制,所以無法判斷使用者是否登陸,以及無法保持使用者狀態,所以就需要一種機制
關於APP介面設計
最近一段時間一直在做APP介面,總結一下APP介面開發過程中的注意事項: 1、效率:介面訪問速度 APP有別於WEB服務,對伺服器端要求是比較嚴格的,在移動端有限的頻寬條件下,要求介面響應速度要快,所有在開發過程中儘量選擇效率高的框架,PHP建議使用YAF框架。 2
app 通知類介面設計
獲取Notification列表 Request { // 獲取未處理的訊息, 最多返回 limit 條 "notifications": { "version": int // 最初版本號為1 "after": long //
iOS和Android的app介面設計規範
最近從一個程式猿變成產品汪了!人生職場的一次轉變吧!從開發人員轉產品,也需要很多基本工具和規範需要學習; 以下是自己對APP設計過程中一些自己寫學習和總結,難免有錯,歡迎指正; 在產品道路成長中,記錄一下iOS和Andoird的介面設計規範,方便進行標準的產
XX公司APP介面設計規範v1
APP介面設計規範v1 張遂程 2018年02月06日16:15:03 前言 沒有最優的方案,只有最適合的方案,本文指出對APP介面設計的一些規範與大家分享和共勉,涉及到APP介面設計規範v1.0,設計案例的分享,和一些PHP編碼的要求,目的在於
Android App 架構設計
簡介 本文是對谷歌原生文件的翻譯,僅供學習參照。 原文連結 此文件寫給希望學習最優程式設計實踐和架構以開發健壯、高質量APP的開發者。 開發者常遇到的問題 傳統的桌面程式大多數使用場景是有一個啟動入口,作為一個獨立程序執行。Android app結
App介面設計規範-字型規範
通過對不同型別的app進行總結,總結出app的字型規範。 一、字型選擇 1.IOS:蘋果ios 9系統開始,系統最新的預設中文字型是:蘋方。英文字型是: San Francisco 2.Android:英文字型:Roboto,中文字型:Noto 二、案例分析 1.以今日頭條介面為例,
ThinkPhp3.2.3 多專案 後臺 APP介面設計 框架設計
↓↓↓專案檔案組成部分↓↓↓ APP檔案是後臺,index.php是入口檔案 Interface檔案是介面,注意這裡不要用api命名!可能會有問題!interface.php是入口檔案 注:兩個入口檔案唯一的區別就是interface比app入口檔案多
如何優雅的定義 App 的介面設計
2014年初,移動端上網的流量第一次超越了PC端,從此確定了移動端取代桌面PC端成為一般大眾接受資訊的主流終端。也正是因為如此越來越多的移動網際網路創業者將自己的產品重心放在了APP上面,然而隨著移動端市場的擴大,APP的數量達到了井噴的狀態,如何在眾多的APP產品中吸引到
APP開發實戰8-API介面設計
3.1介面設計注意事項 (1)首先需要確定APP和伺服器間用什麼格式傳輸資料,常用的有兩種:XML和JSON。如下使用XML格式和JSON格式表示同樣的資料,進行比較: <?xmlversion
基於Java的REST架構風格及介面安全性設計的討論
1.REST即表現層狀態傳遞(Representational [,rɛprɪzɛn'teʃnl] State Transfer,簡稱REST)。 (1)REST名詞解釋: 通俗來講就是資源在網路中以某種表現形式進行狀態轉移。分解開來: Resource:所指的不只