An open API, also known as a public API, is an application programming interface that allows the owner of a network-accessible service to give universal access to consumers of that service, such as developers.
An API is a software intermediary that makes it possible for application programs to interact with each other and share data. It's often an implementation of REST that exposes a specific service or software functionality while protecting the rest of the application.
Open APIs are published on the internet and shared freely. A startup software company, for example, might publish a series of APIs to encourage third-party developers in vertical industries to be innovative and figure out new ways to use the startup's software product. In theory, it's a win-win business arrangement.
Benefits of open APIs
Using an open API, a third-party developer can make money by licensing a new program, a mashup with advanced functionalities or an innovative use of the service being accessed that provides users value in ways the originator of the service had never envisioned.
Meanwhile, the open API's publisher gets to expand its user base without having to spend any money to develop niche industry software -- and it still gets to keep its source code proprietary.
Drawbacks of open APIs
An open API should be treated like any other customer-facing product because the reputation of the company can improve or suffer damage depending upon how the open API is received by the developers using it.
With that in mind, it's crucial to avoid problems with open APIs. Just like any application an organization might release to the public, it is important to ensure an open API:
- Does not contain software bugs;
- Does not perform poorly;
- Does not contain security flaws; and
- Does not leak any private data.
Open API architecture
Open APIs can be designed in a variety of different ways, but the main priority of any open API architecture is the API itself can be easily consumed and accessed by as many different clients as possible.
REST APIs vs. SOAP APIs
The most common open API architectures fall into two categories: REST APIs and SOAP APIs.
SOAP and REST offer different methods to invoke a web service. SOAP-based APIs typically use XML as a data exchange format, while RESTful APIs typically marshal JSON back and forth. Both approaches have supporters and opponents.
The current trend in the industry is largely toward REST APIs and away from SOAP-based APIs. Many older open APIs provide both a SOAP and REST base in order to support older clients, but newer implementations typically only provide REST-based access.
Open API management
Once an API is made public, it is difficult for an organization to control who uses the API and how they use it. As a result, API management must be taken seriously; otherwise, issues can arise in terms of customer satisfaction.
For example, organizations must be careful when they decommission older APIs, change the syntax of a RESTful method call, alter the structure of an XML or JSON payload, or retire a given piece of functionality, as the control that might exist within an organization over how an API is used and who is using it simply does not apply to the public at large.
When changes to an API are not managed properly, end users become disaffected, and that can hurt the reputation of the organization providing the public API.
Open vs. closed APIs
The concept of an open API having access restrictions might sound contradictory, but it is not. An open API, by definition, is openly accessible to the public and can be invoked from anywhere on the open internet.
In contrast, a closed API, also known as a private API, is not accessible openly on the internet. Accessing a closed API normally requires making calls through highly restrictive firewalls or a VPN service, if any external access is allowed at all.
Also, since closed APIs typically reside in highly secure environments, they often do not employ any form of user authentication at all, as it is assumed that every resource making calls to them originates from within a secured and trusted realm. Furthermore, closed APIs are often used for internal services and processes, such as microservices and container orchestration tools, to communicate with each other, whereas open APIs tend to focus on delivering more user-driven services and capabilities.
Open API security
While an open API might be universally accessible, it may also use various means to restrict access, encrypt data transmission and leverage API security measures.
For example, Transport Layer Security (TLS) can encrypt data sent across a network. For authenticating the identity of the caller, SSL certificates prove useful, and any number of back-end authentication mechanisms can map users to the private data that is associated with a given user principle.
Examples of open APIs
There are many uses of open APIs. One of the most common areas for both the availability and consumption of open APIs is in social media.
For example, Facebook provides an open API that allows third-party tools to create photo albums or post to a user's news feed. In fact, Facebook has a built-in function that allows the items you add publicly to your news feed to also be posted to your Twitter feed. In that case, the Facebook application is actually using the open API from Twitter to make that interaction happen.
Many software products also come with an open API, allowing programmatic access to the data they contain. For example, Microsoft's SharePoint collaboration platform provides a REST API that allows access to the FAST Search service. When queried using the open API, authenticated users can query the SharePoint platform for published documents based on date, title, ID and a variety of other attributes.
In a world where systems are increasingly interconnected, organizations are realizing that one way to gain widespread adoption of the services they provide is to make an open API available so the public can access those services in new and creative ways.
An open API case study
The rise of Twitter illustrates the benefits of open APIs, along with the potential drawbacks.
When Twitter started, it provided a text-only format and a rudimentary web-based interface. However, Twitter provided an open API that allowed programmatic access to its systems.
An ecosystem of tools and feature enhancements were quickly developed. TwitPic, which added the ability to share photos through Twitter, became popular. Customizable desktop interfaces, such as TweetDeck and Falcon Pro, earned favor from users who were not impressed by Twitter's own interface. A large part of the Twitter success story was due to the additional features and software applications that were developed using its open API.
However, some of the Twitter clients rejected Twitter advertisements or injected their own ads, which had a negative effect on Twitter's business model. Through acquisitions, API restrictions and trademark challenges, Twitter pushed back against some companies that used its open API.
Some members of the software development community felt betrayed by Twitter. They believed the community that developed apps using Twitter's open API played a large part in why Twitter became successful. Shutting down those APIs and filing trademark infringements against supporting services showed disregard for the many developers who played a part in Twitter's success, some in the community said.
Twitter executives said their moves sought to protect the company's trademarks and intellectual property, as well as the platform's security.