Originally published at:http://www.apiful.io/intro/2015/10/19/api-research.html

Web APIs brought drastic shifts to service computing's practice and research. In many ways, they are the counter-concept to previous services computing paradigms, fostering simplicity and flexibility over agreed-upon capabilities. To help web APIs to reap their full potential research needs to follow novel paths.

The old paradigm of services computing

In the late '90s / early 2000s, the introduction of the Simple Object Access Protocol (SOAP, by now the acronym is used on its own) and the the Web Service Description Language (WSDL) set the stage for extensive efforts to fill the new paradigm of services computing with life. A central idea of related Service-oriented Architectures (SOAs) was to compose applications from reusable services. Anticipating more and more services to exist, functionally equivalent services were supposed to be exchanged dynamically at runtime based on their (timely) non-functional properties and applications were supposed to re-compose in reaction to change. To make this vision reality while preserving qualities of the applications, a plethora of technologies and standards were developed, which are broadly referred to as the Web services stack (WS-*). These standards address concerns like coordination of services, how to compose them, transactions across services, policies, or security. To get a feel of the vast number of technologies and standards, look for example at this overview from the first quarter in 2007. Technologies in WS-*, largely, are prescriptive in nature. They prescribe how to design services and their interfaces in order to offer certain functionalities or fulfill certain qualities.

Despite the completeness of the Web services stack, the adoption of SOAP-based Web services arguably failed to live up to expectations (cf. the increasing determination in related articles from 2008, 2010, and 2013). In my opinion, it is exactly the prescriptive nature of service-oriented technologies that impeded a broader application. Many standards, starting with SOAP and WSDL themselves, are complex in nature and require too much developer experience and effort for many applications. In consequence, web services did not broadly become available outside of individual organizations. Attempts to catalog publicly accessible web services in a global UDDI Business Registry were discontinued.

The emergence of web APIs

Since the mid-2000s web APIs have filled the void for publicly available services. Web APIs expose resource like functionalities or data through web technologies, most notably the Hypertext Transfer Protocol (HTTP). Resources are exposed in machine-understandable ways, for example, data is exposed in the Extensible Markup Language (XML) or the JavaScript Object Notation (JSON).

One reason for the success of web APIs is their simplicity. Because they are based on HTTP, a web API's endpoint exposing GET methods can typically be invoked by simply navigating to the endpoint's URL in any browser. The (experimental) consumption of web APIs, in contrast to SOAP-based services, is thus extremely easy. Web APIs typically implement the REpresentational State Transfer (REST) architectural style for high performance, scalability, simplicity, or, generally, maintainability. However, in contrast to the standards in SOAP-based services, REST does not necessarily be adhered to completely. In fact, different levels of adherence to REST can be separated. In practice, web APIs implement different flavors of REST, they follow different conventions on how their endpoints are designed, on how returned data is structured and encoded, or on how aspects like authentication or encryption are implemented. In contrast to SOAP-based services, common aspects across web APIs are much smaller - every web API provider spins a version that is tailored to their service's specific needs. To me, this flexibility of web APIs, next to their simplicity, is the most convincing argument for their success: services differ tremendously in what they do and how they ideally do it. Service interfaces have to embrace this diversity, and web APIs arguably better do so.

How to research web APIs

While the proliferation of web APIs has made it easier than ever to incorporate data or complex functionalities into applications, many of the desirable capabilities of developed as part of WS-* are not available for web APIs. Most notably, machine-understandable descriptions of web APIs are missing, which are the basis for many higher-level mechanisms like composition or transactions. Despite the existence of many web API description formats, like Swagger, WADL, APIs.json, or API Blueprint, instances of descriptions of public web APIs are not readily available per default.

So, how can research address this gap? In my opinion, it needs to welcome that today's web API space is highly complex and diverse. This diversity needs to be considered, but it should also be embraced, because it is the reason the web APIs are so successful. Proposed solutions should not, as in the SOAP days, try to prescribe how to achieve certain capabilities or assume web APIs to be homogeneous. Rather, proposed solutions need to observe how web APIs are designed and offer unintrusive solutions that developers can easily opt-in, without needing to change how they provide or consume APIs. For example, API descriptions should ideally be created automatically from collectable data on APIs, rather than having developers create and maintain them. Composition of APIs should be enabled by flexible adapters, automatically translating resources between the APIs. Or, capabilities and qualities of APIs should be dynamically discovered, rather than exposed in predefined policies. To achieve these goals, research on web APIs depends heavily on the collection and processing of unstructured or semistructured data to learn about, cope with, and build solutions for most diverse web APIs. In consequence, on top of solid knowledge about the past and state of the art of services computing, this shift requires researchers to be familiar with additional techniques like data mining, data analysis, or machine learning. Here at IBM Research, with the recent focus on cognitive computing, technologies like IBM Watson or the Alchemy APIs are ideal candidates to be used. The spread of web APIs offers great opportunities for services computing as a discipline to evolve, while at the same time narrowing in to some of its original goals.