In the previous article, I defined API Lifecycle and API Design, mentioning examples of tools which may be useful on the subsequent stages of API development.
As I finished my explanation of implementing an API into the IT infrastructure of an organisation in the previous article, today I’d like to focus on other important issues, such as:
security and access control
monitoring the use of the service
change management in an API Lifecycle
versioning and withdrawing an API from use
Security, access control and limitation
Securing the services provided by supplier is one of the most important elements of the strategy based on interaction with external systems using an API. The main assumption is that the shared interfaces are used only by authorised instances, known to their owner (except for unsecured public services).
How to control the access to the shared service?
Common standards serve to achieve a specific goal, among which are OpenID and OAuth. The former supports authentication – that is introducing yourself to the “other party”. The latter allows authorisation of the particular subjects in communication, i.e. verification of whether the requester has access to specific resources. These two mechanisms can go hand in hand. The additional use of SSL certificates for encrypting communication paths gives a comprehensive solution in the area of API security.
Possible ways to control access to the shared service are:
authentication using SSL certificates,
API key (Basic/Digest Auth),
access tokens compatible with OAuth.
In addition to the Boolean protection of access to the API Lifecycle itself, there are also methods for limiting the volume of requests to it (i.e. throttling). In the API Gateway tools it’s possible to define many criteria of the limitations (global, per user, per access token or per IP address). The possible reasons for using these practices are:
the intention to achieve the so-called API monetisation, for instance charging fees for unlimited access to the service or for each call
performance limitations in the IT infrastructure.
If you want to ensure the highest level of availability and efficiency of the implemented API Lifecycle, it’s useful to have in place procedures on monitoring the service usage and reactions to any deviations from the standard.
These activities should be carried out using dedicated tools that constantly monitor the functioning of the component, analysing both the ‘software’ and ‘hardware’ aspects.When detecting any of unwanted events, the system should notify previously defined recipients.
Examples of tools supporting this process are the full ELK stack (Elasticsearch, Logstash, Kibana) and Grafana.
Only change is certain, says the proverb. That’s why it’s also necessary to be able to introduce improvements into the API”.
From the point of view of a service owner, both interaction with API consumers andimplementation process of the new version of the service are very important. These elements require the presence of a communication channel shared by all parties and a transparent messaging with a reasonable notice period.
When making changes to API, you need to collect technical and business arguments that answer the following question: “Should the new version be backward compatible?” and “Will the existing users be able to use the modified API without additional adaptation once the the new version gets implemented?”.
Despite being a very desirable business feature, it’s extremely difficult to implement, especially in the case where the structure of the supported requests is subject to modifications. A solution to this problem is maintaining several parallel versions of the API along with the gradual withdrawal of the archival versions.
However, this generates additional workload related to coordinating work in an environment with many “active” versions of the service, giving rise to errors, requests for changes and questions from clients to every version.
Versioning an API Lifecycle from use
The natural stage in the process of creating and using a given service is its withdrawal from productive use. This could entail the entire service or only its specific version.
There are many reasons to use it, such as:
disappearance of a business need,
emergence of another service that includes the functionality of the existing API,
creation of a new version containing the implementation of significant changes
Along with the withdrawal of an API, the support for clients of a given service or its version also ends. The organisation providing the service has to face the challenge of effectively informing the existing users about its withdrawal / replacement and coordinating this work so that the whole process is “painless” for its clients.
We hope you liked our introduction to API Lifecycle. If you’re interested in this issue, make sure you read our previous posts: