What is an Open API?

Contributed by: 
Carl Reed

ProgrammableWeb, an online news and directory for web-based application programming interfaces (APIs) references more than 13,900 APIs, which is up from 6,000 registered APIs in May 2012. This phenomenal growth! The number one category of web APIS by far is Mapping with more than 4,500 APIs. This is more than Social, Mobile or Finance! Perhaps this is why over the last 6 months there has been considerable discussion in the Open Geospatial Consortium (OGC) concerning APIs: What is an API, is there an ontology for classifying APIs, does the OGC develop APIs, and so forth. A critical element of these discussions is the concept of what is an Open API. There are those in the geospatial community that an Open API is, well, completely open. The API is free, unencumbered by any IPR, has a non-restrictive license, is open source, and most importantly does not require a proprietary software stack to actually use the API. While most anyone in the geospatial and broader IT world would agree on most of the listed aspects of an Open API, the last “requirement” of not accessing a proprietary software stack is counter to current IT best practices.

Current IT best practices define an Open API as a freely available API that provides a developer with programmatic access to a software application or service. The programmatic access is typically to proprietary software stacks but can also be to open source software, or a combination of both. These APIs use sets of technologies that enable websites and/or client applications to interact with each other by using REST, SOAP, JavaScript and other web technologies.  These APIs have allowed web communities to create an open architecture for sharing content and data between communities and applications.  A very typical application for an Open API is to access data: tweets, geolocation(s), maps, stock quotes, weather sensors, and so forth. An Open API is published on the internet and is free to use by anyone – including a company’s competitors. Further, the licenses for most Open APIs tend to be unrestrictive – such as similar to Creative Commons or the Apache license. Do not confuse the API license with the Terms of Use/Service (ToS) related to any data accessed by the API!! This is a very important distinction. ToS related to data accessed by the API tend to be very restrictive – just check out the Twitter or Google ToS.

Why do companies and organizations publish Open APIs that can be used by anyone including competitors? Innovation is fostered wherever APIs are available. Open APIs, because they are accessible to developers outside of an individual business, can attract new and often unexpected innovation by enabling your core business service to be “remixed” by others outside of an organization. A company might publish 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 this way, a company can increase market reach without the traditional major investments required to open new markets.

Apigee, a builder of API management platform software, (http://apigee.com/about/blog/technology/why-and-how-apis-open-api-model ) summarizes these  Open API value propositions as:

Breakthrough innovationInnovation by leveraging the creativity and know-how of hundreds of thousands of developers around the world using your API to create cool apps and make big breakthroughs.

Niche markets: A company may have a geographical or demographic niche that represents a nice new value proposition for the business. But it may not have the resources or the budget to get the value proposition into those niches. Taking advantage of an open API program, any developer can create an app that generates new value for both themselves and the API provider.

Direct incentives: A directed approach may be to run a contest or a hackathon and an incentive to build against your API. Google does this on a regular basis. This approach extends R&D budgets and resources beyond the borders of your business and spurs innovation on a broad scale.

There is also an interesting value proposition that is not often documented.  Any developer can take an API definition and implement the same interfaces defined in the existing Open API as part of their own software stack. Sure, they would be giving credit to your competitor but why spend significant R&D dollars to replicate a well-designed and successful API? If your core software provides better and faster functionality, this approach makes it very easy for a developer to switch platforms. This brings us back to standards and the OGC. Standardized APIs can be implemented on any proprietary platform.

Most Open APIs have a strong reliance on standards: OATH (authentication), OpenSearch (share search results), JSON, SOAP, ISO 8601 (date and time), and many more. From an OGC perspective, there are many (hundreds?) of APIs that reference OGC interface and encoding standards. These API implementations of OGC standards are providing new requirements into the OGC standards process – and the ongoing discussions in the OGC about the role of APIs in the OGC standards development process. In another blog I will talk about what makes a good API.

In future blogs on Open APIs, I will address topics such as the relationship between Open APIs and open source, how to determine if an Open SPI is any good or not, and any topics suggested by the readers of this blog.