An application program interface (API) is a set of functions, protocols, procedures, and rules for building software applications and governing how they function. APIs equally allow for communication between software; making it possible to transfer data and access resources from one server to another. APIs serve as the on-ramp to the digital world, allowing tasks as simple as ordering pizza from your mobile device to occur easily.
API usage has grown tremendously in the past decade, most notably in the past year, as more organizations continue to adopt and actively use them. Expectedly, as APIs continue to become more widely adopted, so has their focus as an attack vector by threat actors. In a survey conducted for 2022, it was reported that malicious API attack traffic surged 117% over the year, from an average of 12.22M malicious calls per month to an average of 26.46M calls. This is a staggering statistic that Security professionals and API developers have to note when securing, managing, and building APIs.
Building APIs
When building APIs, there is often a focus on the functionality of the API in terms of what it does and what service it provides while often neglecting its usability, ease of adoption, flexibility, and, most importantly, security. Thus, looking at APIs from the same lens as the typical UI is important. When a UI is designed well, users trust and are loyal to it due to the seamless experience it provides. This seamless experience covers usability, ease of adoption, flexibility, and security.
While an API does not have the visual representation of a UI, the policies to be adopted when building one are similar.
Top Priorities to consider when creating an API
Before we dive in, it is important to note that when creating an API, the developers should shift their perspective to that of an API user from that of an API designer. This ensures that the right policies are prioritized and adopted. That being said, the top priorities when creating an API are:
o Documentation: Documentation is pretty much a no-brainer. Documenting an API should be the priority of any developer as it ensures that both old and new users optimize usage of the APIs with the aid of simple and clear-cut steps or instructions on how to use the API. Simply put, consumers of APIs would require documentation as a form of guidance to understand the available functionality, the data required, and the data returned when using an API.
As easy as documenting APIs might seem, a good number of APIs do not have clear-cut documentation or outdated documentation. This can potentially leave some features in the realm of being unknown to end users, negatively affecting the usability, alongside its seamless adoption.
o Security: API security can be defined as the processes involved in protecting APIs against misuse and cyber-attacks. It is important to note that overall API security has greatly improved over the past year with the adoption of certain practices aimed at improving API security and safety of use. These practices mainly focus on the use of authentication, encryption, API gateway management, throttling limits and quotas, and data validation.
When building APIs however, the key security focus should be on authentication, authorization, and encryption. Authentication ensures that the right end-user or program has access to the resources provided by the API. While authorization deals with granting or denying access to the resources provided by the API. Encryption, on the other hand, scrambles the data to a format that is not human-readable while the data is in transit to its intended user.
The best and currently the most widely used API authorization framework is OAuth2.0, a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user.
o Stability: Building stable APIs is as important as building secure ones. Considering APIs are still software and software constantly changes as more features are added, optimized, and/or removed, it is important to have a clear versioning strategy when building APIs. This versioning strategy should be adopted at the get-go as it helps ensure that the API consumers are kept abreast of breaking changes made which may or may not affect functionality.
If possible also, when an API version is updated, the new version should be made backward compatible. This gives API consumers enough time to adapt to changes so there isn’t that feeling of being blindsided.
It is also often best practice to have the API version number as part of the URL with API responses in the form of meta-information. A good example can be seen in the URL “hxxp://footballscoreapi.com/api/widgets/v1”.
o Flexibility: API flexibility comes into play concerning request validation. As simple as the concept of making API flexible might seem, in reality, it is a daily struggle for API developers.
This is because it is challenging to be 100% prepared for the unlimited ways an API can be used. For example, an API can support a wide variety of formats but will only support a specific format in the URL itself. Thus, API flexibility comes into place. Some ways APIs can be made flexible to cater to request validation are:
o Allowing for the particular format to be specified in the URL (e.g. /api/v1/widgets.json)
o Allowing the code to read and recognize an Accept: application/json HTTP headers
o Allowing case-sensitive inputs so users can specify inputs
o Supporting a query string variable such as ?format=JSON
o Allowing different ways of inputting variables such as XML, and basic POST variables
o Supporting standard POST variables.
Conclusion
As the need for APIs continue to increase globally and organizations need to build and push out new APIs regularly, it is important to prioritize the aforementioned policies. These policies not only ensure that your APIs remain clean, well-documented, user-friendly, adaptable, easily adoptable, and secure, but they also help build user confidence in your products, thus also aiding your business development and growth needs.
Top comments (0)