Helping Your Customers Operate Throughout The API LIfe Cycle

29 Mar 2017

When I started API Evangelist back in 2010 the only stop along the API life cycle that service providers were talking about was API management. In 2017, there are numerous stops along the API life cycle 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 their customers are able to seamlessly weave multiple service providers together to address their full life cycle of needs.

While Restlet is developing tooling to help companies define what the API life cycle 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 load them into potentially other API services, allow API operators to get what they need done. In my opinion, making API definitions just as importan tas any other service or tooling you offer along the API life cycle.

Serving a single or handful of stops along the API life cycle 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, and 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 life cycle, but after watching companies come and go for the last seven years, the one's that don't support API definitions won't be around too long.