App后端服务器开发小结

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`之类的技术推动下,后端的一些工作就能轻松很多了.