Helping Your Customers Operate Throughout the API Lifecycle
After watching companies come and go for the last seven years, the ones that don't support API definitions won't be around too long.
Join the DZone community and get the full member experience.Join For Free
When I started API Evangelist back in 2010, the only stop along the API lifecycle that service providers were talking about was API management. In 2017, there are numerous stops along the API lifecycle from design to testing, all the way to deprecation. The leading API providers are expanding the number of stops they service, and the smart ones are making sure that if they only service on or two stops. They do so by providing via API definitions like OpenAPI, ensuring that their customers are able to seamlessly weave multiple service providers together to address their full lifecycle of needs.
I've been working with my partner Restlet to advise them on expanding their platform to be what I consider to be an API lifecycle provider. When I first was introduced to Restlet, they were the original open-source, enterprise-grade API deployment framework. Then, Restlet became a cloud API deployment and management provider, and with their acquisition of DHC, they also became an API client and testing provider. Now, with their latest update, they have worked hard to help their developer and business customers service almost every stop along a modern API lifecycle from design to deprecation.
While Restlet is developing tooling to help companies define what the API lifecycle means to them, the heartbeat of what Restlet delivers centers around API definitions like OpenAPI and RAML. API definitions provide the framework when your designing, deploying, documenting, managing, and testing your APIs using Restlet. They also provide the ability for you to get your API definitions in and out of the platform and to load them into potentially other API services, allowing API operators to get done what they need to get done. In my opinion, making API definitions just as important as any other service or tooling you offer along the API lifecycle.
Serving a single or handful of stops along the API lifecycle can be today's version of vendor lockin. If your customers cannot easily load their API definitions in and out of your system, you are locking them in, and while they may stay with you for a while, eventually they will need additional services. The extra work it takes to keep in sync with your platform will increase and eventually, it won't be worth staying. I'm a big fan of companies doing one thing and doing it well, servicing single stops along the API lifecycle — but after watching companies come and go for the last seven years, the ones that don't support API definitions won't be around too long.
Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.