.png){kind=small}
.png){kind=small}
Surely, you have heard a common term when the subject is APIs, which is Developer Experience (DX). This term is slightly reminiscent of UX, and that is not by accident, as both are about appropriate experiences for a specific person.
In the case of DX, obviously, the focus is the Developer and, as in any process of creating experience, some tools are necessary to allow your API to evolve in the right direction, guaranteeing the best experience for you.
The scope of tools is varied and may include simple analysis or more complex structures such as Artificial Intelligence. Today, we will show a few suggestions on how to evolve an API based on data analysis. For starters, it is always interesting to have a tool that can deliver this data.
In the case of Sensedia API Platform, we use Kibana.
In addition to Kibana, an important feature for this type of analysis is the tool’s Trace feature. In case you are not familiar with it, Trace is the ability to analyze in detail all the requests that occur in the Gateway, as shown in the image below.
With this Kibana analysis, it is easy to get interesting insights on API improvements or even good consumer practices for your developer. From now on, we will show a few situations observed at Sensedia, in some cases with our clients.
On those occasions, it was possible to obtain insights on how to improve an API for the target audience for which it was developed.
The first step to start improving your API, based on data that your analytics and API Management tool can offer, is to investigate all 404 requests that arrive at your Gateway.
Imagine that you have the client features, but the display is in English.
GET http://miurl/v1/clients
When working in the Brazilian market, many of the requests with 404 response will be for visual accommodation, that is, their users will be making the request
GET http://miurl/v1/clients
With this observation made through the data received, it is interesting to implement the following return to help the user experience:
{
“Error”: “not-found”;
“Message”: “Not Found. Did you mean ‘/clients’?”;
“Status_code”: 404
}
With this change, validating the most common errors of its users, it is possible to improve the experience and prevent the developer from having to return to the developer portal to validate again the correct resource to be executed, which should enable successful requests to happen quickly.
Something very interesting that can be verified in requests made in your developer portal is the number of possible clients that are converted for production, that is, the volume of Access Tokens created promoted for production after a trial period with their APIs.
When comparing the conversion data of companies that used the same keys for sandbox and production with those that had a more bureaucratic process with generation of new keys, there is a considerable difference. Thus, once again, Kibana’s analytical data was very important, but in order to use this ease of movement across environments in the tokens, it is necessary that its API Management tool have that feature, because otherwise, the work will be large or even unfeasible.
In this third case, the analysis approach is the backend itself, so that you can deliver a better experience with better response times for your audience of developers.
As we can see in the graph below, there are two large peaks of backend latency in the time period described. In this case, there are two APIs – one that is very constant and another that is oscillating.
Although this example presents very irrelevant peaks, since the maximum latency reached 800 milliseconds, it is a good example to demonstrate how this analysis is performed.
When there are peaks in backend latency, it is necessary to adjust the behavior of the API with interceptors, which will measure and control the Spike Arrest (number of peak requests) in its backend. In addition, a very interesting practice to prevent the request from reaching its backend is the use of the cache system of your API Management tool.
In this way, the developer will always have faster and more precise answers, allowing the development of the application that will use its API much more efficiently and making its API more interesting.
This fourth case is very interesting and is similar to the analysis of the first case but has a more internal characteristic than directing the developer to make the request correctly.
The analysis of errors can always be a differentiator even in specific societies, because in case your partner is being blocked by 429 errors (number of requests exceeded), you will be able to offer a better plan to that partner and obtain more income with its API.
Of course, in addition to the financial benefits, you can observe the main types of errors that occur in your API requests, such as wrong date format.
Imagine that your API has a GET feature in which one of the parameters is the start date. You will surely specify the date on which your backend accepts in your API documentation, but in the construction of an application, it may be the case that the developers fail to notice the type of date offered by their API.
Thus, one of the benefits that you can give your developer is to understand the most widely used types of dates when sending applications to your backend and move on to support them.
With such changes, you will ensure that more people can use your API more easily and quickly, which is the goal when it comes to DX.
The last case in this post will address the proactive support to the users of your API. This example is very delicate but very important, as developers are people, and people can always be helped with a human touch.
When are you able to perceive common errors of understanding in the API and in use?
Through the Access Tokens, it is possible to segment people who are making those errors in your API. It also allows you to send emails to those developers, offering a proactive help to use your API and a business understanding.
This help is essential to achieve even more engaged developers, who may be facing difficulty using your API. This action aims to create a relationship with the consumers of your API, to provide not only better results, but also a broader experience and variation in uses.
We have seen in this article some important points in building DX, but surely there are many more. If you have any questions, please write it in the comments or post a comment with a topic that you think it would be interesting to explain in more detail.
Do you want to know more? Talk to one of our specialists, just fill the form below and soon we will get in touch ;)
