Experience in APP data interface development, app data interface development

Experience in APP data interface development, app data interface development

When I got such a task, I didn't feel any pressure. Isn't it just providing data to mobile applications? Parameters sent over there, data processed here, And JSON is returned. Ajax is often used for website development to request background data. Isn't that the case. As a result, I started to work after I confirmed the requirements. Soon, I entered the joint debugging stage. At this time, I encountered various problems and was too busy. After the project, the project is summarized as follows:

1. When should I add interfaces.
When a page does not require a second request, an interface is used, such as a general details page or personal information page. If a single page function requires a second request, for a list page with the paging function, an interface is used. The page contains multiple functions. If there is one that requires a second request, multiple interfaces need to be defined, for example, if the personal information page contains a to-do list and pagination is supported, if an interface returns all information, the personal information will be refreshed every time you flip the page, in this way, unnecessary information is transmitted.

2. Try to make the interface URL easy to understand and beautiful.
When creating an interface, you should consider the interface address. The file directory should not be too deep. In my opinion, it should not exceed three layers. The layers should be consistent with the menu layers of the APP, at least the maintenance in the future will be much more convenient. The interface address should not be changed easily, including adding parameters, because this will cause the APP to be repackaged. If it is already online, it means the APP needs to be upgraded.

3. Parameters and return values.
First, let's talk about the parameters. The author's current practice is to use URL-based parameter passing, POST-based parameter passing, JSON string-based data submission, and POST-based deletion. Besides, the return value is the same. All interfaces in the project Return JOSN data in a unified manner, and a format is agreed. For example, this JSON object contains three keys: data, msg, and status, it represents the returned data, which may be an object or array, request feedback information and feedback status code. This eliminates the need to declare each interface. Let's talk about some details. In advanced languages, there are multiple types of data, such as String, Int, and DateTime. After being serialized as JSON, all the fields are converted to strings. When this parameter is null, you must note that the serialized values are expressed as null, no quotation marks; if it is not null, the value is the default value, and there are no quotation marks, while DateTime is enclosed by quotation marks, "0001-01-01T00: 00: 00". If there is no value for a String of the reference type, after serialization, it also becomes null, rather than the empty String "". To use the empty String ", you must give a default value, such as String. empty, said this because iOS told me that when the field value returned null, they reported an error. Another problem is that the precision of the numeric type was encountered before. At that time, the interface returned a price field. The server certainly used the decimal type and kept two decimal places, however, the iOS side receives many more digits after the decimal point, and Android has no problem, so it has to be converted to the string type before serialization. Other numeric types that need to contain decimal places. When the decimal points are all 0, the data is serialized to an integer type. In this case, the data must be converted to a string before serialization. For the DateTime type, when receiving the value as an added or modified parameter, it is to be inserted to the database after deserialization. If you use SQL Server exactly and use the DateTime type, note that the range is 1753-01-01 00:00:00 to 9999-12-31 23:59:59, And the empty string is converted to "0001-01-01 00:00:00", an exception is reported. Finally, I feel that there are no special circumstances. Can all fields return strings to the mobile terminal? For example, if the time type is displayed on the mobile phone to date, I will not return the time, minute, and second, return as a string. In this way, the product will display the time, minute, and second, and it will be OK after processing in the background. Is that true?

4. interface joint debugging.
The joint debugging includes two meanings: 1. Remote debugging in the VS environment. There are many methods available on the Internet, so I will not talk about them here. Another meaning is to test software functions with mobile terminals. This project did not actually perform remote debugging several times. Because detailed debugging logs are recorded, most problems can be quickly located. Debugging logs generally contain key variable values in the current environment and information about the current method.

5. handle errors and return error codes.
First, do not directly send exceptions to the caller. In this way, neither experience nor error locating are beneficial. Instead, capture the logs in the background, record the detailed logs, define a set of global error codes, and return the corresponding error codes to the interface caller. I personally think that exception capture should be handled, but it should not be the best. The outermost layer should be wrapped in try catch and logs should be recorded to ensure that exceptions will not be thrown to the caller, for other locations that use unmanaged resources, capture the logs, release the resources, and continue to throw errors.

Vi. Interface documentation.
When it comes to writing documents, programmers seem to be disgusted by nature, but it seems impossible to Develop interfaces without writing documents. They also need to write standards that others can understand. Writing a good interface document is really a permanent task. Writing a good document saves much more time than writing a document. Of course, you must update the document in time and synchronize it with the program. Common interface documents include functions, request methods (GET/POST), addresses, parameters, return values, request examples, return examples, global security authentication methods, and error codes.

The purpose of this article is to summarize the interface development work in the past few months. The result is dragged on for several days. After writing the work, I find it a little bad. In this article, the handling methods or understanding of knowledge may not be very correct. I hope you will leave valuable suggestions.