Just like many concepts in Computer Science, APIs come in all shapes and sizes. The traditional program or library level APIs now have many new siblings thanks to web APIs. These two classes of APIs have much in common in terms of philosophy but differ greatly in implementation. APIs permit developers to rapidly introduce capabilities into applications without the need to develop the actual code that implements the capability. Thanks to the explosion of Software-as-a-Service offerings and the advent of microservices architectures it is difficult to find a desired capability that doesn’t have a public API.
At IBM Research, our group focuses on web enabled APIs and understanding the ways that businesses can effectively build enabling platforms and supporting ecosystems for these APIs to thrive within. More broadly this has been referred to as the API Economy.
The community has consolidated on Representational State Transfer (REST) as a simpler and more effective method for integrating a disparate set of applications and services. However, despite agreeing on REST in principle, there are still many instances of “REST-like” or even (my term) “REST-get”1 APIs being introduced.
Web APIs expose some capability of value for reuse. What exactly the capability is can vary significantly between different API providers. In some cases this value is the ability to perform some proprietary function or calculation (IBM Watson APIs), access resources programatically (IBM Decision Optimization on Cloud) or simply the ability to access data (New York Government). In other cases APIs can represent an entire set of applications and associated business workflows (Salesforce).
Function-based APIs are focused on providing some unique calculation logic as a module of reuse. The Watson APIs are good examples of these as the developer must provide the data but the Watson service provides the algorithms. These APIs are particularly attractive to take advantage of protected IP without entering into complicated legal negotiations. They also allow developers to freely move between services providing the data is interchangable (which in the case of “text” it always is).
Data-based APIs are unique in that they typically just serve data. Their offering to the developer is information. It is then up to the developer to pair that information with other application function in an interesting way for end user consumption. Many of these services are strictly GET endpoints with little in the way of data manipulation. These APIs offer a quick way to turn a legacy database into something that is easily integrated by the broader community (internal or external). Inside Research we have experimented with dreamfactory and had a great deal of success in enabling developers to innovate around a DB2 dataset that was historically very difficult to gain access to. The one caveat to these data-based feeds is that they leave out the “CUD” part of CRUD. Yes, POST and PUT operations can be overlaid but it is really just a web-SQL interface. Still important and convenient but not a substitute for building in true application functionality.
Application-based APIs combine the elements of data and function in a way that is unique to consume in a particular business domain and use case. For example, not only does GoogleAnalytics act as the store for usage information about web site traffic but it also provides a number of functions to perform on the data. These are functions that make sense in the context and state of the data collected as well as the context of the more specific traffic analytics service.
Despite the drastic change that we, the community, have seen to date thanks to APIs, this is really just the beginning. As legacy systems catch-up and more companies realize that APIs aren’t a nice-to-have but a must-have we’ll see that the ability to access anything programmatically will be taken for granted. Without a doubt the next generation will also open the ability for individuals other than professional developers to consume APIs and leverage them for many more use cases (i.e. a service like IFTTT is already there).
We look forward to exploring many topics on web APIs in this blog and look forward to hearing your thoughts and ideas as well.
- REST-get - a “REST” api that only has GET calls
Curious what Watson Analytics thought of this post? Well here is the result from Watson tone analysis: