API Management: Retiring your API
- Jitu Ranjan
- Jul 16, 2023
- 2 min read
According to MarketsandMarkets, the API management market is projected to be worth $5.1 billion by 2023. With API-as-a-Product & API management trending in today's industry, the API lifecycle should also follow a similar trend and should have a well-defined EoL
There has been a recent boom in the number of API management vendors who are thriving to manage an API life-cycle fully. With my experience working for some API-first companies I have rarely seen a capability that laid out a reference/guiding principle to deprecate an unused/legacy API. With 83% of entire web traffic using API services today, it's important to have a mechanism to gracefully end APIs not being used.
Following are some of the key motivations, why one should think through and layout capabilities to deprecate/define the end-of-life of an existing API
Housekeeping
Better developer experience (DX)
Fast adoption of new releases
Reduced maintenance overhead
Security concerns
Following are some findings, which sound like a logical option and are followed by a few known companies
A technical solution defined by IETF proposes a standard in the form of an HTTP header to notify deprecation/sunsetting
“The Deprecation HTTP Header Field” currently is an Internet-Draft (I-D) and defines the Deprecation HTTP header field.
“The Sunset HTTP Header Field” is Internet RFC 8594 and defines the Sunset HTTP header field.
Making use of official communication over web portals, GIT repository or social media handles ensures consistency.
As a final thought, it would be great to see a few automated policies which cater to end-of-life use cases for an API from known API management vendors. This is certainly not just deprecating/deleting an API from the management plane but also injecting the right headers with logical details like dates, alternatives or communication links, etc.
Comments