The Application Programming Interface (API) is a key computer science concept that allows developers to build rich applications that tap into and provide a mash-up of other, typically web-based, applications. By exposing their applications through well-documented and easy to understand interfaces (definitions and protocols), Facebook, Google and others are able to consolidate their position at the center of the web and smartphone app economy.

Now communications service providers (CSPs) are adopting open API-focused strategies as they develop their own cloud-oriented architectures and that's why we are focusing on this increasingly critical topic during a panel discussion, "How CSPs are Leveraging Open APIs to Make Their Networks More Programmable," at our upcoming Software Defined Operations & the Autonomous Network event in London on November 7-8.

How the API ecosystem has evolved is an example of how the industry must collaborate beyond the traditional standards mechanisms to progress.

While there has been broad agreement for some time that APIs should adhere to the Representational State Transfer (REST) architectural style, a style is not a specification and hence the APIs of one application would look quite different to those of another. Swagger was developed to provide a common approach to APIs based on the concepts of REST, Simple Object Access Protocol (SOAP), Web Services and Remote Procedure Calls (RPC).

In 2015, SmartBear Software, a provider of open source API testing and development tools, acquired the Swagger open source API project from Reverb Technologies and then donated it to a new open source project under the Linux Foundation, the Open API Initiative. The initiative was led by SmartBear in conjunction with Apigee, Google, IBM, Microsoft, PayPal and others.

A year later, the TM Forum launched its Open API Program, which was collaboratively developed by service providers to transform IT, increase operational agility and improve customer focus. The TM Forum Open API is not intended as an alternative to the Linux Foundation project but is a higher-level type of API designed for operational functions that would be familiar to communications service providers -- for example, creating a trouble ticket, or collecting service usage data. There are currently 54 different APIs available including, for example, a Service Ordering Management API that "provides a standardized mechanism for placing a service order with all of the necessary order parameters." The TM Forum Open APIs use Swagger as part of their modelling along with other software tools, such as JSON schema.

How will service providers enable automated and efficient network operations to support NFV & SDN? Find the answers at Light Reading's Software-Defined Operations & the Autonomous Network event in London, November 7-8. Take advantage of this opportunity to learn from and network with industry experts – communications service providers get in free!

In June this year, the Linux Foundation announced that its ONAP project had collaborated with TM Forum on external APIs, ensuring they can communicate seamlessly with the ONAP platform. According to Laurent Leboucher, VP Architecture, Enablers and Security, at Orange Labs, "the Service Order API allows a loose coupling between any BSS system triggering a fulfillment system and an ONAP powered Software Network." Other TM Forum Open APIs incorporated in ONAP's Beijing Release were Service Catalog and Service Inventory.

The open API concept will not just provide a lingua franca for industry collaborative initiatives such as ONAP, it will also allow operators to adopt the platform business model, tapping into a community of global application and cloud providers and exposing their own capabilities via APIs. This platform model is arguably key for CSPs to remain relevant to both their enterprise and consumer customer bases.

— James Crawshaw, Senior Analyst, Heavy Reading