3.1 Interface Design
(1) You need to determine what format the app and server use to transfer data, and there are two common types: XML and JSON. XML file contains a large number of descriptive information, will greatly increase the network transmission of data, the same content, in JSON format, the transmission of less data, the preferred JSON format.
There is also a Protocol buffers format that transfers stored data in a binary way, with less network traffic than Json , but with Proto file as a format verification, each language needs a whole heap of PB runtime and corresponding code generation, increase the complexity of the high, currently not much use.
(2) The specific format of the JSON data needs to be designed:
Send request (no specific parameters)
Send request (with specific parameters not in array format)
Send request (with specific parameters in array format)
Operation succeeded (return only operation status, no data returned)
Operation succeeded (return operation status and non-array data)
Operation succeeded (return operation status and array data)
Operation failed (return operation status and error prompt only)
When defining field names in JSON, try to be as short as possible to reduce network transmission data.
(3) The application side of the JSON format, it is best to use strict mode, as long as the JSON data from the server, and the inconsistency of the contract, whether it is a multi-field, a few fields or field names have changed, the app side should be error, so as to facilitate early detection problems.
(4) Because the interface code on the server side may change, it is best to bring the version number of the interface on the app side when sending the request to the server side.
If the version of the interface used in the old app is 1.0, the interface is updated to version 1.1 after the online, and the 1.0 version is not compatible, the user may not update the app or use the old version of the app.
After the server has received the request, it is found that the app uses an interface version of 1.0, which can call the old interface to process the app request, which is difficult to handle if the request does not have a version number.
(5) Apps often need to get pictures from the server, but the server's pictures are often not completely suitable for the application needs, you need to first on the server side by the app needs to process the pictures, and then the processed pictures to the app; When sending a request for a picture, the app sends the width and height of the desired image to the server, such as the Get command, which can be used as follows:
http://www.hello.com/getimage/2/width/100/hight/100
When the server receives the request, it can process the picture according to the size required by the app and send it to the app.
(can also be implemented with the post command)
(6) Most apps and servers interact with the HTTP protocol, each sending a request to the server to establish a connection, transfer data, and then disconnect, even if the server side has a connection pool design, but the connection pool to accommodate the number of connections is limited.
In the design of the interface, every action performed on the app side, as far as possible only to send a request to the server, but also to reduce the app in the display of new pages, the number of requests sent to reduce the app and server to establish connection and disconnect the time and resources consumed by the program to improve the response speed.
(7) The interface that returns array data to the app should be designed to support paging operations, providing parameters for the app-side settings to get the starting position of the element and the number of fetches:
There are 100 elements in the array, but the app side may get only 10 elements from the 1th element for the first time, and a second time from the 11th element to get only 5 elements.
This is required for the e-commerce app to get a list of items and a list of orders.
App development Combat 8-API interface Design