Experience on app Architecture Design: interface design

Tag: Send request with date War ARC error message security blank number

http://blog.csdn.net/utilc/article/details/50495830

The communication interface between the app and the server is well designed, and there are a lot of places to think about, and here are some of my experiences to do some summary sharing.

Design of security mechanism

Now, most apps have a restful architecture, and one of the most important design principles of restful is that client-server interactions are stateless between requests-that is, when a user state is involved, each request has authentication information. Implementation, the majority of the use of token authentication method, the general process is:

1. After the user logs in successfully, the server returns token to the client;
2. The client stores tokens locally and sends tokens back to the server when initiating subsequent related requests;
3. The server checks the validity of tokens, valid returns data, if invalid, in two cases:
   • Token error, which requires the user to log back in to obtain the correct token
   • Token expires, the client needs to initiate an authentication request to obtain a new token

However, there is a security problem with this type of authentication: When the login interface is hijacked, the hacker acquires the user's password and token, and subsequently can do anything to the user. The user can regain control only by changing the password.

How to optimize it? The first solution is to use HTTPS. HTTPS on the basis of HTTP added SSL security protocol, automatic data compression encryption, in a certain program can prevent monitoring, prevent hijacking, prevent re-send, security can improve a lot. However, SSL is not completely secure, and there is the possibility of hijacking. In addition, the server to the HTTPS configuration is a bit more complex, but also to the CA to request a certificate, and generally charged. Moreover, HTTPS efficiency is also relatively low. In general, only systems with high security requirements will use HTTPS, such as banks. And most of the apps that don't have that high security requirements are using HTTP.

Our current practice is to add signatures to each interface. Assign a key to the client, each time the interface is requested, the key and all parameters are combined into a source string, according to the signature algorithm to generate the signature value, send the request when the signature sent to the server authentication. Similar implementations can refer to the OAuth1.0 signature algorithm. In this way, the hacker does not know the key, do not know the signature algorithm, even if interception to the login interface, subsequent requests will not be successful operation. However, because the signature algorithm is cumbersome, and error-prone, only suitable for internal interface. If your interface is an open API, it is not very suitable for this type of signature authentication, it is recommended to use the OAuth2.0 authentication mechanism.

We also assign a appkey to each end, such as Android, IOS, and three terminals, each assigned a appkey and a key. No Appkey request will be error, the wrong Appkey request will also error. In this way, security has added a layer of defense, but also convenient to different end to do some different processing strategies.

In addition, now more and more apps to cancel the password login, and the use of mobile phone number + SMS Verification Code login method, I also used in the current project this way of login. There are several benefits to this sign-in approach:

1. Do not need to register, do not need to change the password, and do not need to forget the password and reset the password operation;
2. Users no longer need to remember the password, but also not afraid of the problem of password leakage;
3. Its security has improved significantly with respect to password logons.

Design of interface Data

Interface data is generally transmitted in JSON format, however, it should be noted that the value of JSON is only six data types:

• Number: integer or floating-point number
• String: Strings
• Boolean:true or False
• Array: arrays contain square brackets [] in
• Object: Objects are contained in curly braces {}
• Null: null Type

Therefore, the data type of the transmission cannot exceed these six data types. Previously, we have tried to transfer the date type, it will be similar to the "January 7, 2016 09:17 42 seconds gmt+08:00" Such a string, which will cause problems in the conversion, different analytic library resolution may be different, some may be confused, some may be directly abnormal. To avoid errors, you have to do special processing, you do the analysis manually. To eradicate this problem, the best solution is to use the number of milliseconds to represent the date.

In addition, the previous project also appeared in the string "true" and "false", or the number of strings, or even the string "null", resulting in parsing errors, especially "null", causing the app to crash, and later looked for a long time to find out is the problem caused. This is because the server does not handle the data well, causing some data to be converted into strings. Therefore, in the client, also can not fully trust the data returned by the server is correct, you need to do all the exception conditions are handled accordingly.

The data structure returned by the server is typically:

{    code:0    "Success"    data}}    

• Code: Status Code, 0 for success, not 0 for different kinds of errors
• Message: Description information, success is "Success", error message when wrong
• Data: Returned on success, type is object or data

Different errors need to define different status codes, which are client-side errors and server errors, such as 1XX indicates a client error, and 2XX represents a server error. Here are a few examples:

• 0: Success
• 100: Request Error
• 101: Missing Appkey
• 102: Missing Signature
• 103: Missing parameters
• 200: Server Error
• 201: Service Not available
• 202: Server is rebooting

Error messages generally have two purposes: first, when the client developer Debugs to see what the error is, and second, as the app error prompt to display directly to the user to see. The main or as an app error prompt, directly show to the user to see. So, most of them are short tips.

The data field will only be returned if the request succeeds. The data type is scoped to an object or array, and the object is returned when the requested data is a single object, or an array of objects when the requested data is a list. It is important to note that you should not pass data into a string or number, even if the request requires only one data, such as token, the returned data should be:

Correct     } error 123456  

Design of the interface version

Interfaces cannot be immutable, and in constant iterations, there will always be changes. There are several general changes to the interface:

• Data changes, such as adding data types that are not supported by older versions
• Parameter changes, such as new parameters
• The interface is deprecated and the interface is no longer used

In order to adapt to these changes, the interface version design must be done. Implementation, there are generally two ways:

1. Each interface has its own version, typically adding a version parameter to the interface.
2. The entire interface system has a unified version, generally add a version number in the URL, such as http://api.domain.com/v2.

In most cases, the first approach is to overlay the version number on this interface and be compatible with the old version when an interface changes. When a new version of the app is developed, the new version will be passed in.

If the root of the entire interface system changes, such as the microblog API, from OAuth1.0 to OAuth2.0, the entire API is upgraded.

Sometimes, a change in one interface can affect other interfaces, but it's not always possible to find out when doing it. Therefore, it is advisable to have a well-established testing mechanism to ensure that every interface change can be tested to all relevant levels.

Experience on app Architecture Design: interface design