Think carefully about API language standards

How API standards have changed

In the past, there were no official API language standards so each application had to create its own proprietary APIs, with the hope that they would become the standard for other developers to follow.

If the API was not simple enough, and it required a level of learning that ate into profits for other companies, then it was not a viable option. Generally, it was easier to bypass the application and go straight in at the database level. This way, you could access data directly from the database using a standardized access mechanism such as SQL. But this approach could have an adverse impact on application security.

The World Wide Web brought about highly standardized API languages, such as HTTP, XML and JSON. Industry bodies, such as the IEEE, or working groups of interested parties, such as application vendors, created and activated these standards. These APIs remain strong even through multiple versions of maturity.

Navigating new standards

At a more granular level of operating system APIs, the Portable Operating System Interface remains the accepted API language standard for many platforms -- like UNIX and Microsoft Windows -- with applications accessing services at the platform.

At a deeper level, it can get somewhat informal. The majority of well-behaved applications will adopt accepted APIs when they talk to the underlying operating system. However, for web-based interactions, trying anything else opens the application up to problems when things change at the OS or network level. However, the functions within the application itself that are surfaced to other applications (for example, functions such as billing, reporting or process integrations) by the API can be anything but standard.

If the vendor is influential, a proprietary API can become a de facto standard. Some examples are AWS's S3 storage API or the multitude of APIs that SAP provides. These types of APIs often become de facto standards as developers adopt them through force majeure.

For everyone else, buckle yourself in and try to use as many accepted standardized chunks of functionality as possible -- such as OAUTH for authorization or JSON for server/browser interactions -- combined with accepted de facto APIs, such as S3. This blend makes it easier for developers to write extra functionality for that application, which can broaden its overall appeal.

API management comes into play

However, this practice is imperfect and this is what fuels the market for API management tools. These tools can help complex organizations with a large number of applications, where they may not want the responsibility to ensure that all API calls are fit for purpose and checked as different systems evolve.

Platforms, such as Microsoft Azure, AWS and Google Cloud Platform, now come with simple API management capabilities. These capabilities are often embedded into the platform, are well documented and their integration is built into many modern DevOps tools. Third party tools, such as MuleSoft, Apigee and WSO2, offer some advanced capabilities. These tools can help create APIs, deal with updates and patches, monitor, manage and report on interactions between systems that use the APIs. These tools also ease worries that involve manual API management, where human error can inject problems, for example through scripts containing typing errors or code containing hard-wired code rather than abstracting through the API.

In the current era of the API economy, no application exists in a vacuum without dependencies or surrounded by other systems. Adopting APIs is a given. But it requires due diligence to ensure that such adoption does not result in more problems. First, judge how well providers adopt open standards and how much they depend on proprietary ones. Then embrace the need for extra tooling to establish optimized, real-time API management.