I wrote a post about the emails I get from folks telling me the API definitions contained within my API stack research, something that has helped me better see why it is I do API definitions. I go through APIs and craft OpenAPI Specs for them because it helps me understand the value each company offers, while also helping me discover interesting APIs and the healthy practices behind them.

The reason why I create API definitions and organize them into collections is all about discovery. While some of the APIs I will be putting to use, most of them just help me better understand the world of APIs and the value and the intent behind the companies who are doing the most interesting things in the space.

I would love it if all my API definitions were 100% certified, and included complete information about the request, response, and security models, but just having the surface area defined makes me happy. My intention is to try and provide as complete of a definition as possible, but the primary stop along the API lifecycle I'm looking to serve is discovery, with other ones like design, mocking, deployment, testing, SDKs, and others following after that.

Maybe if we can all better understand the different reasons behind why we all craft and maintain API definitions we can better leverage Github to help make more of them complete. For now, I'll keep working on my definitions, and if you want to contribute head over to the GitHub repo for my work and share any of your own definitions or submit an issue about which APIs you'd like to see included.