I play with a lot of services that target the API space each week, during my regular monitoring of the space. These are services from all along the API lifecycle that service this space, from design to integration, that target both API provider and API consumer. After I on-board with a service, there is one trend I see emerging that really puts service providers into two distinct buckets.
The API focused services that stand out the most, are the ones that employ common API definition formats like Swagger, and API Blueprint. After I've on-boarded with a service, if I can upload a machine readable definition of one or many of my own own, or public APIs I depend on, the quicker I will see a service in action--well on my way to understanding the value generated by a service provider, and becoming a customer.
Examples of this in the wild are:
- SDKs with APIMATIC
- Monitors with API Science
- Tests with Runscope
- Client with Postman
- Documenetation with Gelato
As a service provider, focusing on the API space, if you do not speak Swagger, Postman Collection, or API Blueprint, the chances API providers (or consumers) will be on-boarding and using your service, goes significantly down. This works just like APIs themselves, in that you have to reduce any friction possible when on-boarding. If I can signup using my Github account, and fire up the service with a Swagger, or even better a collection of Swagger APIs using APIs.json, the chances I'll be a customer increase dramatically.
I am adding flags for the common API definition formats, to the system that I use to track on API service providers, and will be highlighting those that speak these formats. After that, I will find a way to showcase which formats these providers support, bringing front and center across my research, and storytelling.
