An open API, also called public API, is an application programming interface made publicly available to software developers. Open APIs are published on the internet and shared freely, allowing the owner of a network-accessible service to give a universal access to consumers.
An API is a software intermediary that makes it possible for application programs to interact with each other and share data. It's often used regarding REST APIs that expose a specific service or software functionality while protecting the rest of the application.
While some may consider open and public APIs an analogous term, some may site a difference in that open APIs are shared freely, and that public APIs -- by comparison -- are commonly more restricted concerning the assets they share. In this case, because the proprietary organization is sharing its own API and back-end data publicly, and wants to maintain a sense of security and management over their application.
Even if implementing an open API may lead to security challenges, a startup software company, for example, might want to publish a series of APIs to encourage third-party developers in vertical industries to be innovative; figuring out new ways to use the startup's software product. In theory, it's a win-win business arrangement.
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 use 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 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 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.
Open vs. closed APIs
Even though there are some well-known and popular Open APIs such as Jenkins Remote Access API and GitLab API, most APIs are actually closed APIs -- meaning their private. This privacy is different from the form of security found in open APIs. An open API has access restrictions because they are openly accessible to the public and can be invoked from anywhere on the open internet.
On the other hand, 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.
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.
Also, 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.
Benefits of open APIs
Benefits of open APIs include benefits for both the API publisher and the developers who want to use the publishers API.
For the publisher, benefits include:
- The ability to get to expand their user base without having to spend any money to develop niche industry software.
- Using an open API, a third-party developer can make money by licensing a new program
- The organization also still keeps its source code
For other developers, benefits of open APIs include:
- Reduced dependencies such as between development teams or front-ends and back-ends.
- Saves time and avoid mistakes writing code
- Developers can still use their preferred tools with an open API.
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.
Organizations should ensure any of the possible downsides an open API may have can be avoided. 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.
- Does not leak any private data.
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. Facebook has a built-in function that allows the items a user to add publicly to their news feed to also be posted to their Twitter feed. In that case, the Facebook application is 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 role 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.