Editor's note: Be sure to check out our research on the overall growth of Web APIs since 2005. At the time of writing, this is the most recent data we have, but check the research page to see if we have a more updated article. We will be continually updating the overall growth chart with other charts getting updated on a less frequent basis.
The majority of the APIs within the ProgrammableWeb directory are REST-styled request-and-response APIs, long the de-facto standard in the web API space. However, REST isn't the only architectural style in use, not by a long shot. As use cases for APIs evolve, providers have begun offering multiple APIs to interact with their services. These APIs may follow the RPC style, which includes old-fashioned SOAP as well as gRPC, GraphQL as used by Github, or the Push/Streaming style which includes Webhooks and WebSockets among other technologies.
Push/Streaming APIs are event-driven. This means that when some event happens, data is then sent (or "pushed") in near real-time to a client that's waiting for such updates. In contrast, most REST-styles APIs use the same polling pattern where a client sends a request to a server, the server retrieves the requested data and then returns it back to the client.
Push/Streaming APIs are enabled by a variety of underlying technologies such as Webhooks and WebSockets. But there are others available to providers in order to best enable their APIs for real-time streaming. For example, although it largely follows an RPC-like pattern, gRPC is built on top of HTTP/2 which in turn offers native support for bi-directional (server to client or client to server) streaming.
The question then is raised: what underlying technologies are most popular across the various Push/Streaming APIs that are out there? The data model that backs ProgrammableWeb's API directory allows us to track this. Additionally we also have some insight into the categories where Push/Streaming APIs are seeing traction.
|Push/Streaming API Styles||API Count|
From the table above we can see that Webhooks is the most popular push/streaming technology. Webhooks work where the API provider publishes an event stream that the API consuming application subscribes to. When an event happens (for example, a stock ticker's price changes), the API provider sends the details to a URL endpoint that's operated by the API-consuming application or developer. To the extent that his "push" of data involves API provider doing an HTTP POST to the client, the Webhook approach to push/streaming can be thought of as making RESTful API calls in reverse. Similar to typical request-response RESTful API calls, this call is made to the developer-side API endpoint via a URI Query string and often with a JSON payload.
From ProgrammableWeb's data, we also see that WebSockets is the next most commonly used data format. In a WebSockets strategy, the client asks the server to upgrade the connection protocol from HTTP (the Web) to WS (WebSocket) , often initiating the exchange with a URI query to do so. A WebSocket gateway residing between the client and server then sets up a WebSocket connection that remains open and is bi-directional so that both the consumer and the client can stream to each other. The server then sends data through the WebSocket gateway when updates are available.
Another interesting piece of data that we can look at is what API categories currently involve the most development of Push/Streaming APIs. The chart for the most common categories appears below.
We see that the most commonly used category is Financial. For many Financial APIs, especially those tracking the movement of the stock market, the need for data to be delivered as close to real-time as possible is critical. Using a Push/Streaming architecture for an API is the logical choice for these providers as polling with a RESTful API would be too slow and create too much of a load on the servers. Notifications is a natural category for Webhooks APIs as they can update the user when an event happens such as a Github repository being forked or a new user joining a Slack channel.
The bi-directional nature of WebSockets is attractive when you need real-time updates in both directions. So it shouldn't be surprising to see categories that foster interactive experiences such as Messaging, Chat and Video.
The Push/Streaming architectural style is one that is sure to continue growing as providers seek alternatives to REST styled APIs for applications that need to perform in real-time. Do you have a Push/Streaming API? If you are an API provider, adding a listing in our directory is a great way to improve the discoverability of your APIs and raise awareness of your program. If you would like to include your APIs in our directory, you can use the link below. https://www.programmableweb.com/add/api