Open vs. closed APIs: 4 crucial factors you should examine

Open vs. closed APIs

An open API is accessible by third-party developers, business partners, customers and other external parties via the web. Businesses often use open APIs to allow integration and data sharing between outward-facing applications and software systems. But this does mean secure design and practical API management are both extremely important factors when it comes to open APIs.

A closed API, on the other hand, is one that individuals can only access through an organization's internal IT estate or a private network. Typically, organizations use closed APIs to integrate line-of-business applications with their internal data or back-end systems because of their connection to business-critical systems and sensitive data.

There are no fundamental differences between open and closed APIs in terms of underlying capabilities or build processes. For instance, developers can use SOAP, REST and other common API design models to build either an open or closed API. As for operational concerns, an API will typically integrate with API gateways, monitoring dashboards and other standard management tools regardless of whether it is open or closed.

The top-of-mind factors that developers and architects should consider, however, include things like API security, developer usability, versioning processes and error handling. These are areas where an API's level of exposure truly matters, and each one should absolutely influence the choice to keep an API open or closed.

Security

Security is one of the most important factors when choosing between open vs. closed APIs. Fundamentally, all APIs should be governed by strong authentication and authorization procedures. Developers should strive to enforce policies consistently and review their API security strategies regularly to prevent unwanted intrusions, but the degree to which developers need to secure the API will change depending on its open or closed status.

Because closed APIs are only available to internal stakeholders, they pose somewhat less of a security risk than open APIs that are exposed to external developers. Practically speaking, an ill-intentioned internal developer (or a savvy external attacker) would be capable of infiltrating and abusing a closed API, provided they had the right knowledge or access credentials. However, this is much less likely to occur -- and, generally, more difficult to accomplish -- than someone exploiting an open API available over the web.

Meanwhile, the potential fallout from security incidents involving open APIs can be quite staggering. Attackers often use poorly secured open APIs as vectors for data breaches; in other cases, malicious actors crash servers by manipulating the API and overwhelming the server with continuous calls and service requests. This is a lesson that companies like Facebook, whose open APIs attackers have used to steal data from accounts on more than one occasion, learned the hard way.

This is not to say developers can skimp on security for closed APIs. Nor does it mean the security risks of open APIs eclipse the benefits they provide in terms of connecting with customers and business partners. But it does mean an open API places a heavier security burden on the organization, and developers should take special care never to open up an API that exposes sensitive data or connects directly to business-critical systems.

Usability

Ease of use is often the functional priority when it comes to open APIs. From a business perspective, the usability of open APIs plays a crucial role when trying to cultivate a strong third-party developer ecosystem. In some scenarios, the usability of that API -- or lack thereof -- may even affect a company's brand.

In contrast, with closed APIs, internal developers usually get what they get in terms of usability. Poor usability might make external developers less likely to work with a company's platform, but most are willing to accept a decreased level of usability in exchange for the dependability and security of a closed API.

Ease of use, of course, can strengthen a company's relationship with its partners, but it's probably not in the company's best interest to sacrifice the security of a closed API for usability during the design process.

Versioning

When it comes to versioning, it's often easier to commit updates to closed APIs that remain relatively static. It also stands to reason that fewer developers use a company's closed APIs than those that are open. As such, it should be easier to announce updates, apply new versions of the API consistently for all users and collect actionable feedback when things go wrong.

On the other hand, it usually takes more work to roll out new versions of an open API. Even simple feature updates can prove complex. For instance, developers need to be extra careful that the changes don't break existing functionality for large groups of users.

While important for any API project, developers will also need to go above and beyond when it comes to documentation for open APIs. The documentation will need to be understandable to the general public, make no assumptions about their knowledge, contain a painstaking level of detail about updates and not contain any sensitive information that could lead to a breach.

Error handling

API failure or performance degradation is bad no matter what. But in some respects, the risk is much greater with an open API. The incident may cause third-party developers to stop using a company's API completely. In some cases, it could impact the bottom line of the entire business.

Of course, serious performance issues with closed APIs will disrupt the availability of internal applications and business-critical services. With closed APIs, though, developers typically have full control over the applications that rely on the APIs because they are all internal applications, so workarounds are easier to implement.

From the perspective of overall business reputation and trust within the developer community, open API performance issues tend to cause more harm. It can also be more difficult to mitigate performance issues with open APIs, since pushing changes to the third-party applications is a complex and laborious process. Developers who choose an open API will need to find a delicate balance between providing regular updates to maintain usability and ensuring changes are kept to a reasonable minimum.

Closing open APIs and vice versa

It is possible for developers to alter an API's accessibility post-deployment, but it's rarely easy. As such, it's important to evaluate these requirements as early as possible during the API design process.

But let's imagine that a company's developers deploy an open API that they later decide should be closed due to a security exposure. While it doesn't happen often, a scenario like this can arise when a company rolls out an API without considering long-term management or fails to accurately identify core business requirements. Or the original purpose for the API may have changed, and the new purpose requires that the API be closed to the public.

Since there is no simple way to alter an API from one type to another, developers will need to follow a careful, systematic approach. The first thing to do is ensure the developers who work with that API have time to adjust. Announce the change as early as possible, and consider offering either an older or similar version of the API that can still provide developers with the functionality and resources they would have lost.

When turning an open API into a closed API, it's particularly important to provide documentation that clearly explains what steps developers should take before, during and after the transition. Don't cause frustration by simply announcing the open API is going away and leaving the next steps up to individual developers. That's a recipe for bad relations with external developers, and it can hurt your bottom line much in the same way that poor usability does.

Likewise, to open a closed API, reveal plans well ahead of time so that internal development teams have time to map out their integrations. Make documentation available early, too, so that they can determine exactly what they will be able to do with the open API or identify any potential risks.