API definitions like OpenAPI Spec, API Blueprint, and Postman, have been gaining in popularity over the last couple of years, mostly because of the their ability to deploy interactive documentation like Swagger UI. However, the API providers who have been using them the longest, have also realized these machine readable definitions can be applied effectively at almost every step along a modern API life cycle, from design to deprecation.
I'm always encouraging companies, who are selling software services to the API space (aka API service providers), to make sure and have APIs for their entire stack, as well as speak in as many of the leading API definition formats as you possibly can. To help in this effort, I try to regularly showcase the API service providers who are doing it right--this round, its the folks over at APImetrics.
The screen that comes up, when you go to add new API calls to the monitoring service is exactly what I am talking about, allowing me to get up and running using the API definition format of my choosing.
I am given the option to manually add an API, or do a bulk import of the APIs I wish to monitor using the service. I'm given the option of importing WSDL, OpenAPI Spec, RAML, Blueprint, and Postman, which reflects the leading API definition formats, any API service provider should be speaking by default. If you need help enabling this in your services, I recommend talking to the APIMATIC folks about using their API Transformer.
API definitions are quickly becoming the central contract that gets passed around among technical folks, and increasingly with business units as well. No matter where you exist on the API life cycle, between API design, all the way to deprecation, your customers should be able to onboard, and offboard using all of the modern API definition formats--enabling your users get up and running in seconds, rather than minutes, hours, or even not at all.
