The adoption of Application Programming Interfaces (APIs), open and otherwise, has become a ‘topic du jour’. API usage continues to surge and many API-based tools are emerging to help developers and engineering teams take full advantage of APIs.
At the recent Mobile World Congress (MWC) Barcelona, for example, APIs and API adoption was oft-discussed topics both inside and outside of the meeting rooms. And the pattern continued at Big Data & AI in London.
No doubt — it’s an exciting time to be doing anything API-related.
But there are also challenges appearing around API adoption, some of which developers (and their IT departments) are overlooking at their own risk. Let’s take a look at what APIs are, the two key types of APIs (open and close), and the five important facts to know about API adoption.
What are APIs?
APIs are tools, or mechanisms, that allow disparate software components to communicate with each other and work in unison via specified protocols. A classic API example would be PayPal, which uses an API to allow you to access financial information via your phone so that you can pay for things with your phone.
Open vs Closed APIs
There are both “closed” and “open” APIs. Closed, or private APIs, require a proprietary code to be accessed, Open APIs can be used and accessed by anyone. The point of APIs in general is to make it easier for businesses to connect, and open APIs very much play into this mission.
Open APIs enable the connection between businesses by using a web-based (ie, “REST-ful”) architecture that allows different systems to use them (the APIs) to interact.
There are now a number of well-known open API initiatives such as OpenAPI (formally known as Swagger) and Postman. There are also the telco industry-specific collection of standards-based open APIs that TM Forum developed specifically for use in global telco systems.
As with most new trends in technology, API adoption is not without its hiccups and challenges. We’ll get into those as we look into the five primary things to know about API adoption.
5 Things to Know about Open API Adoption
1. A vendor’s size and amount of legacy code it uses influence how it sees open APIs
Standardized Open API conformance is a challenge for large companies with dozens of customers and millions of lines of code because they need to write a translation layer between the defined API and their existing proprietary API, which is hard coded to work with an intractable legacy data model. This requires time and money and may impact runtime costs, as well. There are also real problems when they drill down into the details of how they do things versus how the open API thinks they should do things. Another factor is that while everyone claims to like the idea of standards, nobody wants to produce products that are strict implementations of them; how do you differentiate your product if it does exactly the same as everyone else’s and nothing more?
For a small telco startup, on the other hand, the TM Forum standards provide a cookbook for what to bring to market and level the playing field with the major players. If you have no existing codebase and want to enter the business having a published standard that defines your ‘minimum viable product’ as a Godsend, especially if the major market players are adding extra features with every release and, in doing so, diluting the value and purpose of their product.
2. Open API certification is now on many Telco-RFPs
When it comes to RFPs, open API certification seems to be following the same trajectory as active-active data center support: it started out as a stretch ‘bond villain’ type of requirement (ie, something that maybe you would do one day when you had an infinite budget), then became a hard requirement, then became ‘table stakes’.
3. Everyone struggles with open APIs for different reasons
Depending on who you talk to, open APIs are either immature, over-engineered, overly academic, too detailed, or too vague.
The problem is that you can’t please everyone.
When the RDBMS became popular, the initial dream was for a single, big corporate schema, and a huge number of hours were wasted trying to get every constituency to agree on a single design.
The same drama is now playing out in the API space: it’s impossible to come up with a single API and schema that keeps everyone happy. You can add customization, for example, but one person’s flexibility is another’s ambiguity.
Regardless of what you decide, in the real world people will do whatever they need to do to make their application ‘fit’ the API, even if it’s potentially not practical.
4. Heterogenous operation is a dream and will remain one
Because of the ambiguity and flexibility of open APIs, you can expect to encounter significant differences in implementation of a given ‘standard’ API between vendors. It’s very difficult to mix clients and servers for the same API, but from different vendors, and expect it to work. This is a logical consequence of different vendors taking different perspectives on how to interpret a given API, especially when they need to make it integrate with their legacy software stack.
This is a bigger issue than it sounds, as once you move beyond the implementation of a single API how do you build a web of different ones to implement a large system if you can’t interoperate clients and servers?
Furthermore, not only is each vendor’s implementation of an open API unique, but per-customer level changes are almost always needed to make everything work. Maybe not big ones, but changes nonetheless.
5. Open APIs are here to stay
While it’s clear that open APIs don’t answer all the questions, they definitely answer a lot of them. That’s why, despite their disadvantages, they are still valuable in the same way that JSON solved the ‘how do I format data to send it somewhere else?’ problem (while leaving the “What does this data I just got mean?” problem unsolved).
It was clear from MWC Barcelona that at least in the telco / mobile space, standardized open APIs are going to heavily influence most new application development moving forward. If there’s a TM Forum spec, even an imperfect one, it’s going to be hard for a telco space product manager to ignore its existence. More and more RFPs mention them, and customers have clear and rational incentives to continue down this road even if the picture for vendors is more ambiguous.
The conclusion: At least within telco, and probably telco-adjacent industries very soon, open APIs are here to stay and will slowly become a mandatory RFP item over the next decade. The key is to be ready for them with a data platform that can handle copious amounts of real-time data efficiently and without sacrificing uptime or data consistency.
To learn more about open APIs and how best to take advantage of them via a no-compromise, real-time data platform, contact us.
