app後端伺服器開發小結

本文來自圖靈社群 by fairjm
轉截請註明出處

---

app的API與網站使用的API較大的區別是其生命週期更長.API的修改需要做到向後相容.
app的API設計要考慮到app的版本問題.API本身需要可以演化.

怎麼拿到App的版本?

這不是一個技術問題而是一個設計問題,需要和app開發協商.
比如User-Agent欄位,讓app傳送請求都帶上一些標誌.
後端建議做成一個工具類,可以從Request中抽取這些資料.
比如:

public AppInfo getAppInfoFromRequest(Request request) {  
 ....  
} 

AppInfo中需要包含系統標識,app標識(應用在一個伺服器服務多個app的情況下)以及app版本.比如 public class AppInfo { private int systemType; private int appType; private String appVersion; ... }

public enum SystemType {
    ANDROID(0),
    IOS(1),
    WP(2);
    private int id;
    .....
}

public enum AppType {
    APP1(0),
    APP2(1);
    private int id;
    ...
}  

有些時候可能app內的webview也要對app做這些判斷
對於安卓可以,一些webview的請求可能無法自定義UA 可以通過X-Requeted-With來判斷
但這樣只能判斷出系統和App型別 版本無法知道

API的演化

這是app端也要做的事. 如果是用JSON的資料,需要app端做JSON物件增加屬性時的相容 舉個例子 如果移動端用jackson做反序列可以讓他們指定一下JsonIgnoreProperties或者在ObjectMapper中進行配置 objectMapper.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES, false) 對於只返回一個String或者返回JSON Array的情況,務必也用JSON Object包裹一下,以免以後需要加屬性造成沒地方可加的尷尬.
對於無法演化的情況,比如app那邊介面大改,已有的介面不能符合,一些欄位的意義改變的情況,可以在API後加上/v2的形式或者在請求引數中加上?version=2的方式,看個人喜好.

WebView使用場景

適合使用WebView的頁面是版本無關的. 比如一個頁面,在1.1版本中主色調是綠色,在1.2版本中是紅色,在1.3版本中是黃色.以後再改變新版本樣式但需要老版本保持不變.對於這種不同的版本需求不同,為何不用native來做?
工作中最多的一次一個url對應了6個頁面,本來挺簡單的一個action因為要相容2個app的3個版本做成了一大坨.
如果是因為工作量的問題,建議頁面的地址由後端提供API給,而不是在移動端寫死.

新技術推動

react native之類的技術推動下,後端的一些工作就能輕鬆很多了.