I like my API service providers like I like my APIs, doing one thing and doing it well.
Sure services can work together (using APIs), and companies can launch multiple services, but I prefer selecting the services that I use as part of my API operations, as small, modular pieces of API infrastructure. In my opinion, API service providers are just another class of API provider, they just happen to be selling services to businesses that are operating APIs.
You can see this in action with API Docs, part of the StopLight.io platform. API Docs does one thing well — API documentation! Although for me, it touches on two important areas of the API lifecycle, both documentation and definitions, but also illustrates the maturation of these stops along the API life cycle, since Tony first launched Swagger UI. The StopLight team is taking API definitions to the next level, but they are also helping us better deliver the documentation portion of our API life cycle(s) — all driven by API definitions. (meta)
If you are looking for another example of this in action, take a look at API transformer, from the APIMATIC team. APIMATIC alone fits my definition of a modular API service provider, doing SDKs, and doing the well, but then you factor in their API translation tooling. #winning Again, APIMATIC is focusing on modular services, that are API definition driven–very similar to what StopLight is up to with their strategy.
In 2016, you will hear me hammer on three key concepts when it comes to delivering services in the API space, and selling to individual API providers:
- Do one thing and do it well,
- Speak in API definition formats, and
- Do it with APIs!!
It isn’t rocket surgery that API service providers should be practicing what they preach, but in 2016 I am finding that these three characteristics are proving to be a reliable way for me to differentiate the API service providers who will be here for the long haul, and those that won’t.