Debugging API Driven Applications

API driven applications are distributed applications. Distributed applications in the simplest terms have a client and a server connected over a network. API consumer is the client, API provider is the service.

When API client and API server interact with each other, we need to understand the invocation flow and what could go wrong with each component at each step of the flow.

The API client and API server interaction flow will have the API client application, client and API server connection, API service hosted at the server, API server to database connection and the database used by the API to store data.

Paying attention to the separation of the layers and checking each layer one at a time in a systematic manner is curtail in getting to the root of the problem when debugging API driven applications. Hence, when you are debugging an API driven application stack, you need to follow the following steps.

Client working?

First check if the client application is working. Rather than blaming it on the API and API hosting side, we need to check if the client application is functioning as expected. Unit testing and developer testing the application locally is important in this step. We need to verify that the logic at the client side is working correctly.

Client slow?

Sometimes, it could be that the client application is working, but it is slow. So, it is important to evaluate the speed of operation of the client application. This could be done with a simple model. One step is measuring the time between initial user action and API request dispatching from client application. This will find the time to process and from the request. Second is measuring the time between the receipt of the response from the API and the time it takes to display the results to the user. The measurement of these two time slots will indicate if the issue is slowness on the part of the client application.

Connection to API works?

If the client application is all working right, then before jumping into conclusions on API errors, we need to check the connectivity between the client application and the API provider service.

It could be that both the client and the service are functional, but the network connection between them are broken. Hence, check for the connectivity, from the machine running the client application to the machine hosting the API service. You can do this by simply accessing a Web page hosted on the API server.

The other method to test network connectivity is to use the ‘ping’ command. Ping command works on both Linux-like platforms and Windows platform. Note that, however, on some networks, ping is disabled for security reasons, and that does not always mean the network is not functional. Hence, if ping does not work, try another method to test network functionality before jumping into conclusions, however, if it works, then you know that the network if fuctional.

API working?  

If the connection between client application machine and API server is working, then the next step is to check if the API is working. For checking if the API is working, if you have access to the API hosting machine, you can invoke the API locally. If not, you can call the API remotely, with a request and see if you get a valid response.

For API testing invocations, you can use a test client program such as the Postman API client.

API slow?

Similar to the client application being slow, it could be the case that API is working but the API execution is slow. To see if the API is slow, you need to measure the time between the moment the request is received by the API and the moment the response is generated by the API. If this time is not reasonable, then you will have to dig into the details of the API execution and explore the logic to see where it is going slow.

API could also become slow because the API hosting machine is slow. Monitoring and analyzing the load average of the server is a common practice to verify that the server machine is operating normal.

DB connection works?

APIs use databases to store data in relation to resources. Databases are critical part of the application implementation logic. At times, it could be the case that the connection between the API implementation and the database server is not functional.  The simple test, like in the case of API client and API server, is to ping or connect from API server to database server and test for connectivity.

DB is working?

Sometimes, even though there is connectivity between API server and database server, it could be that the database is down. To make sure that the database is working, you can use a database client from a remote machine and execute some queries against the database that the API uses to make sure that the database is functional.

Database slow?

Database servers host multiple databases. It is not only the database that your API is using that is hosted in a database server. Therefore, it is a common situation that the database is slow and hence we would face issues with API functionality. There are many causes that can lead to a slow database. Few important aspects you should check include database indexing, slow queries and the load average of the database server.

Indexing the database will make sure that the database is capable of responding to your SQL queries faster. Please make sure that you have done proper indexing using the techniques provided by your database management system.

Sometimes the queries used could be inefficient and that makes the database slow. There are various techniques provided by each database management systems to deepest slow queries. For example, MySQL provides means to detect slow queries.

The other aspect that you have to pay attention to is the load average of the machine hosting the database. If the machine is loaded, then the database response time too will be slow.

Divide and Conquer Principle

We have discussed multiple aspects that you should pay attention to when debugging an API. Rather than treating the whole system as a black box and struggling with finding where the issue is, it is simpler to divide the system into separate concerns and look for problems in each of those layers. That will make your life easy as well as will get you to the root cause in quick time.