Six big pitfalls encountered when calling third-party interfaces

I believe everyone has felt the current market situation, and interviews are becoming more and more difficult, from technical jargon to business scenarios. Today, I bring you 6 pitfalls related to third-party interface calls. The questions are not difficult, but if you are suddenly asked in the interview, you may be a little confused to answer. Although you know them, you may not be able to answer them well.

Next, I will lead you through the whole process. Please leave an impression after reading it. I have also prepared the notes for you. Please deduct 1 in the comment area and send me a private message to claim it. You can also come and complain about some of the pitfalls you have encountered, so that more friends can see and communicate together.

Without further ado, let’s get down to business.

Domain name not accessible

The first problem is that the domain name cannot be accessed. Generally, when we first connect to the API interface of a third-party platform, we may call it through a browser or postman.

There are two aspects to this point: either there is something wrong with me or there is something wrong with the other party.

• Your own network problem
• The other party's domain name is not accessible
• The other party's DNS resolution has a problem
• The other party's service is not deployed, etc.
• The other party has set up an access whitelist

It is possible that when you call the API interface of a third-party platform, their interface is really down and they don’t know it yet. Another most important situation is whether your work network can access the external network interface.

For security reasons, some companies set up firewalls for the intranet development environment, or have some other restrictions, such as IP whitelists, which can only access some designated external network interfaces.

If you find that the domain name you are visiting is not accessible in the development environment, you need to ask the operation and maintenance staff to add the IP to the whitelist for you.

The interface suddenly did not return data

If you call an API interface of a third-party platform to query data, there will be data returned at the beginning. But suddenly one day, no data is returned. However, the API interface can respond normally. Don't be surprised, it may be that the third-party platform has deleted the data.

After I connected the API interface of the third-party platform and deployed it to the test environment, I found that their interface did not return any data. The reason was that they deleted all the data in the test environment one day. Therefore, before deploying the test environment, you must first communicate with the other party about which data to use for testing and which data cannot be deleted.

Another point is that in our own programs, we should never trust the data from third-party platforms. If something goes wrong, we should write a fault-tolerant strategy. We cannot let our system crash because of the mistakes of third parties.

Token expiration

Some platforms’ API interfaces require you to call another API interface to obtain a token before making a request, and then carry the token information in the header to access other business API interfaces. In fact, most of our own systems are designed in this way.

In the API interface for obtaining token, we need to pass in information such as account number, password, and key. This information is different for each interface connection party.

Before requesting other API interfaces, do we call the token acquisition interface once in real time to obtain the token? Or do we request the token once, cache it in redis, and then directly obtain data from redis?

Obviously, we prefer the latter, because if we call the token acquisition interface once in real time to obtain the token before requesting other API interfaces each time, the interface will be requested twice each time, which will have some impact on performance.

If the requested token is saved in redis, another problem will arise: token expiration.

The token we obtain by calling the third-party platform's token interface generally has a validity period, such as 1 day, 1 month, etc.

Within the validity period, the API interface can be accessed normally. If the token expires, the API interface is not allowed to be accessed.

That's easy. We just need to set the expiration time of redis to be the same as the validity period of the token, right?

The idea is good, but there are problems.

How can you ensure that the server time of your system is exactly the same as the server time of the third-party platform?

I have come across a large company that provides a token acquisition interface. If you make a request within 30 days, the same token value will be returned each time. If more than 30 days have passed, a new token will be returned.

It is possible that the server time of your system is faster, while the time of the third-party platform is slower. As a result, after 30 days, your system calls the third-party platform's token acquisition interface to obtain the old token, which is updated to redis.

After a period of time, the token becomes invalid, and your system still uses the old token to access other API interfaces of the third-party platform, which always returns failure. However, it takes 30 days to obtain a new token, which is too long.

For specific error codes, a retry mechanism should be designed:

To solve this problem, you need to catch the token expiration exception. If you find that the token is invalid when calling other API interfaces, immediately request the token acquisition interface and update the new token to redis immediately.

This can basically solve the token expiration problem and also ensure the stability and performance of accessing other interfaces as much as possible.

Interface timeout

After the system is launched, the most common problem when calling third-party API interfaces is interface timeout. There is a very complex link between the system and the external system, and problems in many links in the middle may affect the response time of the API interface.

This is very embarrassing. We cannot control other people's systems. If you ask others to optimize their systems, it may take them half a month to set up a project, adjust it and launch it online. This is still a good situation. Some may take half a year. Others are experiencing your system. It is understandable that it is a little slower. If it always times out and fails, it will be fed back to the user level. The first person the user will look for is you...

As the caller of the API interface, when faced with the timeout problem of the third-party API interface, in addition to giving them feedback on the problem and optimizing the interface performance.

A more effective way for us may be to add a failed retry mechanism for interface calls.

For example:

• If the interface call fails, the program will automatically retry 3 times immediately.
• If the retry succeeds, the API call is successful.
• If the call fails after 3 retries, the API call fails.

Secretly changed the parameters

I have previously called the API interface of a certain platform to obtain the status of indicators. According to the agreement between the two parties, there are two statuses: normal and disabled.

Then the status is updated to our indicator table. Later, the systems of both parties were online and running for several months. Suddenly one day, a user reported that a certain data was deleted, but it could still be found on the page. At this time, I checked our indicator table and found that the status was normal.

Then check the API interface log of the platform and find that the status of the indicator returned is: removed from the shelves.

What the hell, I have already said this in my mind eight hundred times...

After communicating with the developers of the platform, we found that they changed the enumeration of the status, adding multiple values ​​such as "on the shelf" and "off the shelf", and did not notify us. This is a pitfall. In our code, if the status is not disabled, it is considered to be normal.

The delisted status was automatically judged as a normal status. After communicating with the other party, they confirmed that the delisted status was an abnormal status and the indicator should not be displayed. They changed the data and temporarily solved the problem of the indicator. Later, they changed back to the previous status enumeration value according to the interface document.

There is another solution here, which is to return the enumeration information through an interface and then display it, which can avoid the problems mentioned above.

The interface is sometimes good and sometimes bad

I don't know if you have ever encountered a situation where the interface is sometimes good and sometimes bad when calling a third-party interface. 5 minutes ago, the interface was still returning data normally.

After 5 minutes, the interface returned 503 Unavailable. After a few minutes, the interface was able to return data normally again.

Possible scenarios:

• In this case, it is most likely that the third-party platform is restarting the service. During the restart process, the service may be temporarily unavailable.
• The third-party interface deploys multiple service nodes, and some of the service nodes are down. This will also cause the return value to be good or bad when requesting the third-party interface.
• The configuration of the gateway was not updated in time, and the offline services were not removed. As a result, when the user request passed through the gateway, the gateway forwarded it to the offline service, causing the service to be unavailable. The gateway forwarded the request to the normal service, and the service was able to return normally.

If you encounter this problem, report it to the third-party platform as soon as possible and add a retry mechanism for interface failures.