The web connects organisations around the world through versatile software powered by a simple three-letter acronym, API, which stands for application programming interface. APIs provide businesses with a way to share information and connect disparate systems together, and can even generate new revenue streams. Although many may not know this, APIs have become the vascular system of digital enterprise transactions, pumping data from one system to another in a constant flow of 1s and 0s.
While APIs have become so central to business, many enterprises fail to understand they can create a revenue opportunity for savvy channel firms. Indeed, one of the most significant opportunities lies in the fact there is rarely agreement, internally or externally, as to how or when APIs are considered during the development process. Software developers often enable API access as an afterthought, thinking it’s no different to access for website traffic.
This approach which centres on architecture, security, robustness, and so on, can create problems for connected systems and, ultimately, users and customers that depend on API access. What happens when data output from an API is malformed, for example?
All of this can lead to system break down; data doesn’t flow, revenue generation comes to a halt, and, worse, the potential for intrusion grows exponentially. To prevent this, resellers can step in and add value by ensuring that a customer’s APIs don’t fall victim to inadequate design.
Where to start with APIs
Organisations must recognise that API traffic is different to traditional web traffic; in that every API request can be a read or write. They have different HTTP methods and treat URLs differently, with each client API call being independent. Understanding these differences will help you realise the effects that APIs can have on the existing application environment and infrastructure. Once you understand the differences, you need to follow three steps to ensure that your API initiative will be successful.
The first step is assessing impact. Before you code anything, design documents need to assess how the API will interact with relative systems and software. For example, if the API is carrying out a computational task after retrieving data from multiple data sources, what impact will the projected concurrent user requests have on those systems? Can the API be exploited in a computationally-expensive way?
For example, an airline flight routing API might be taken down by an attacker searching for the cheapest route from A - Z with 24 stopovers in between. This is especially important if those systems, like a database, are being employed by other applications. And, what about security? Will API authentication need to be managed by existing security systems (like an LDAP server) or require something new to be deployed (like an OAuth server)? These impacts should be clearly documented with failover contingencies, to enable programmers to have a clear picture of how to architect the API.
The second step is to ascertain the organisational impact in building and launching the API. Which team will architect it? Program it? Deploy, maintain, and support it? For example, your organisation may have a corporate policy of a multi-tenant load balancer that handles all traffic, but your API team needs to have control over the rules that govern its software so they can make configuration changes as needed. There may be considerable delay or disruption to API operation if they have to wait for a centralised function to make rule changes. Deciding to deploy APIs may require a new infrastructure approach.
No one size fits all
The final step is developing a maintenance plan. Often, when APIs are deployed reactively, there isn’t any sense of how to care for them long-term. Supporting systems may change or be upgraded over time, but will such updates break API functionality? Or will new system versions provide opportunities for improved API performance or features? The only way to realise those new benefits is for a team to take ownership of the API’s lifecycle. When that happens, teams can plan to assess each API on a regular basis.
Owning the API lifecycle also takes deprecation into consideration. Sure, no one wants to talk about programming something and, in the same breath, about how to turn if off forever, but it may be necessary to shelve an API at some point. Understanding what’s required in doing that will be critical to a graceful migration of those API users to some other means for accomplishing what they need.
Even if you follow these three steps, it’s important to understand that there is no one-size-fits-all approach to API development. Some organisations will develop their APIs by employing a centralised team while others will develop them in a distributed format, with individual application teams responsible for their own APIs. Once again, it comes back to knowing the customer and understanding how they manage APIs; by adding consultancy and offering support, resellers can be well-placed to remedy challenges and add strategic value to the entire development process.
Owen Garrett is senior director product management at NGINX
