3 min read
Automation Trends: Top APIs to use in 2023
An application programming interface is all around us and will be even more in the trend of automation in 2023. They are used to access data that...
4 min read
Coralie Champion
:
May 23, 2022 9:00:00 AM
Why do you need to think of API as a product?
These internal technology assets have the potential to be the revenue-generating assets of tomorrow. But how do you make your APIs valuable? You have to create and use them as if they were a product:
To ensure that APIs will create value from the start, it is essential to create them as demand-driven products – a demand that is willing to pay to use the product and therefore provide a good user experience.
Take an outside perspective and think more about the needs of your target users. For example, what style of API design do your consumers prefer? Is it REST, GraphQL, or a mix of both? If you build an API program without considering the needs of your target audience, it may not see the light of day.
If you don't know where to start, here are the basic rules to create and choose an API that will last over time:
The documentation must be accessible and complete.
Look for an OpenAPI (ex Swagger) file, which mean this API is following standard methods.
API Key is the simplest to use, OAuth 2 is the more secure but will be more technical for your users.
The best is to have interactive documentation with the possibility to generate test requests.
And SDK available in many languages is nice to have. If you have already an OpenAPI file, it's possible to generate them automatically.
Think about “how” the API is going to be used, by which users or automated services so that you never have something too complex for quick adoption.
You also need to think about the tools and capabilities of the customers to program their requests. If they are too complex, they will have difficulty launching them and therefore using the API.
Good respect for the simplest standards ensures good compatibility. Is there rate-limiting? Is it flexible enough for my use?
As seen before, authenticating an API is one of the keys to easy and quality use for you and your customers, so which solution should you choose?
Follow the standards of authentication: no need to be creative or innovative on this part. The aim is to be used by most users and integration systems. Go with an API key inside a header (and/or a query parameter) or a Bearer Token (inside an Authorization header) are among the most used methods.
Documentation and an example of how to authentication request is a must-have.
Embrace OAuth2 if you can: that'll give to your users more control and more granularity with permissions.
We often think that everything will work without problems and forever, so how to manage the stability of its integrations? What tools to use, what are the standards, what solution to prevent your customers, and how to know if your API is always stable?
Measure the average response time and measure the 95th percentile: see if the measured times are in line with the functioning of the platform. The ideal is to be under 200ms for the feeling of “real-time” and 100ms for the feeling of immediacy.
The 95th percentile says that 95% of the time, the usage is below this amount: so, the remaining 5% of the time, the usage is above that amount.
You should ask yourself:
Don't forget to add a full error message, some context, and an error code. That'll help your users to be autonomous and figure out what's going on.
Make sure the API responds with the right HTTP errors and does not have 500 “generic” errors with messages in them.
Some classic errors to use inside your API:
Main errors:
If other 400 or 500: use customized messages.
Behaviors to avoid:
Never send a 200 code response with the error message inside. 2xx code response is for success only.
Take into account how the team is notified and, above all, how the errors are handled by the team: this is to be managed after the monitoring, but these are good questions to ask because, beyond the tools, there is the subsequent management by the team of the information reported.
To create a quality document, here are some points you need to make sure:
You have many great documentation systems, some open-source (like Docusaurus, Redoc, Slate) and some commercial (Stoplight, Bump.sh, ReadMe, Gitbook) to do it.
Stick with some that allow you to import a standard specification file like Swagger or OpenAPI: that'll give you more freedom, a common file for collaboration and you'll be able to leverage all others tools on this standard (take a look at openapi.tools).
Some tools allow you to generate snippets of code or even allow users to run tests requests (like Swagger UI). That will help your users a lot by figuring out how the request should be formatted and to test without having to start their own development environment for testing a request.
Maintaining a changelog is a great way to inform your users of any change. It's the best if you have the capability to inform your users on any change: you'll be able to release new features with confidence and with potential feedbacks from your users.
3 min read
An application programming interface is all around us and will be even more in the trend of automation in 2023. They are used to access data that...
2 min read
You may encounter errors while creating your automation with Meta API: that’s part of any coding activities (yes, you’re a coder when you use Meta...
4 min read
Making questionnaires can be very useful for your company. Indeed, there are many types of surveys that allow you to get precious information. For...