App backend server development summary

This article is from iteye http://fair-jm.iteye.com/ Please indicate the source

The big difference between the API of the app and the API used by the website is that its life cycle is longer. The modification of the API needs to be backward compatible.

The API design of the app should take into account the version of the app. The API itself needs to be able to evolve.

How to get the version of the app?

This is not a technical issue but a design issue that needs to be negotiated with the app development.

For example, the User-Agent field, let the app send requests with some flags.

The backend is recommended to be made into a tool class that can extract these data from Request.

for example:

public AppInfo getAppInfoFromRequest(Request request) {

....

}

`AppInfo` needs to contain the system ID, app ID (in the case of a server serving multiple apps) and app version. For example

	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;
		...
	}

Sometimes the webview in the app may also make these judgments on the app

For Android, yes, some webview requests may not be able to customize UA. It can be judged by `X-Requeted-With`

But this can only determine the system and App type version can not know

Evolution of APIs

This is also what the app should do.

If it uses `JSON` data, it needs to be compatible when adding attributes to the JSON object on the app side.

For example, if the mobile terminal uses jackson for deserialization, they can specify `JsonIgnoreProperties` or configure it in ObjectMapper

`objectMapper.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES, false) `

For the case of only returning a `String` or returning a `JSON Array`, be sure to also wrap it with `JSON Object`, so as to avoid the embarrassment that there is no place to add attributes in the future.

For situations that cannot be evolved, for example, the interface on the app side is greatly changed, the existing interface cannot be conformed to, and the meaning of some fields changes, you can add the form of `/v2` after the API or add `? The version=2` method depends on personal preference.

WebView usage scenarios

Pages suitable for using WebView are version independent.

For example, for a page, the main color is green in version 1.1, red in version 1.2, and yellow in version 1.3. The style of the new version will be changed in the future, but the old version needs to remain unchanged. For such different versions, the requirements are different, Why not do it natively?

At work, one url corresponds to 6 pages at a time. It was a very simple action because it had to be compatible with 3 versions of 2 apps.

If it is due to workload problems, it is recommended that the address of the page be provided by the backend API, rather than hard-coded on the mobile terminal.

New technology push

Driven by technologies like `react native`, some work in the backend can be much easier.

App backend server development summary

Guess you like