We have been profiling a large number of APIs as part of an effort to populate the Streamdata.io API Gallery. We are creating OpenAPI definitions for each of the APIs we add, which provides us with a pretty comprehensive view of the surface area of each API. After completing an OpenAPI, it is pretty easy to assess the overall maturity of an API platform, and identify how far along in their API journey they are. Something that often translates pretty quickly to whether or not they are ready for, and able to put to use our streaming API services.
One sign of a mature API platform is the presence of webhooks, and documentation around the types of events that are occurring across the platform, in which the webhooks will be responding to. These are the valuable, meaningful events that are occurring amidst all the noise, that API consumers and providers want to be notified of. The API providers who have begun the work to identify and cater to these events are further along in their API journey and have a much more mature way of looking at the activity that occurs via their operations. You can take a look at a few of the API rockstars out there today if you want an example of this in action.
– Github – Event types and payloads for the social coding platform.
– Slack – Event types that work with the Slack message events API.
– Stripe – The event types used to manage payments via the Stripe API.
– SendGrid – Event types used in support of the email API SendGrid.
– Twilio – Webhook events for the Twilio SMS, Voice, and messaging APIs.
These are some of the best known API providers in the space today. There is a reason they are actively documenting the events that occur via their platform, and provide webhook support for them. Using the OpenAPI definitions we’ve generated for the APIs we are profiling, we can easily generate a similar API event type map for each platform we are profiling. Taking the resources being exposed as part of API operations, and using the HTTP verb to describe the type of events involved with each resource. Essentially mapping where an API provider will be, or should be focusing when it comes to understanding the meaningful events that occur via their platform.
Many API providers we approach won’t be ready for our services for their API platform. We don’t see this as a problem. We see this as an opportunity. We want to help our customers streamline the data they generate and depend on as part of their operations. We want to help them see, identify and map out the meaningful events that are occurring, and begin develop a strategy for not just their API operation, but for the future of their event-driven architecture. It’s not whether or not they need real time streaming services, it is a question of whether or not their operations are mature enough to be able to take full advantage of this type of approach to doing business with APIs.
Follow us on social