In practice, we often find that many students directly request to call and read interface data without judging the status code, which is very unreasonable from a design perspective. In addition, for some interfaces that do not have high real-time requirements, a more reasonable approach should be to first pull the data to the local cache, and then read the data from the cache and display it to the front-end user.
1. The status code must be determined before calling the interface.
Never assume that the network is unobstructed. Even if major Internet companies such as BAT are still large enterprises starting with the Chinese character, network failures occur from time to time. Although we have adopted a series of technical measures to avoid such situations, some unplanned network failures cannot be completely avoided. Therefore, if you do not make a good judgment of the HTTP network status code, it may cause unexpected crashes in your project. In addition to the HTTP status code, when calling Tianxing Data, regardless of success or failure, a field code representing the interface status code and description information msg will be returned, which is convenient for everyone to judge the various statuses of the current request interface. Only when the code is equal to 200, the logic of the next step is performed. To be more rigorous, you should perform non-null or type judgments on the fields you will read.
For example, the interface of "Earth-flavored Love Talk", code=200 when the request is normal and the data is successfully returned:
And on bad request:
The explanation of all status codes can be found on the interface documentation, interface application, interface debugging, and call record pages.
2. It is recommended to call the interface data to cache first.
Some interfaces, such as "weather forecast", do not have high real-time requirements and will not be updated all the time. You can call the interface every 10 minutes or half an hour, and setData (write the data returned by the interface to the cache) first. The front-end interface only reads the data in the local cache instead of directly reading the API interface. The advantages of this are that, first, local read-only is more efficient and faster; second, if there is a problem with the interface, including insufficient number of requests, overclocking, etc., interface errors will not be thrown directly to the user. The correct approach should be to make a judgment on the current time (time) for each request. When the time in the cache is less than the current time for more than 10 minutes or half an hour, re-request the interface to update the data in the cache. In this way, whether there is a problem with the user's own network or a problem with the API interface, the user will have no sense of it. Only when he opens it frequently will he find that the weather information seems to have not changed. You can make a manual update button and give a prompt whether the update is successful or failed.