{"API Evangelist"}

Targeting Some APIs In My Stack For House Cleaning And Maybe Some Design Iterations

As I look through more APIs, and I don’t just play around in their developer portal, and look at documentation, I am actually get my hands dirty generating Swagger definitions, and authenticating and making calls to an API. There is no better way to get to know an API, that generating a Swagger definition, and integrating with it—something when done, you always walk away with a new perspective.

Once I get more of the APIs profiled in my API Stack, I’m going to see if I can configure my API editor to let me iterate on other people’s API designs a little bit. As an API consumer, you don’t always get a voice in the design of the next version of an API, but with API definitions like Swagger and API Blueprint, you can actually make edits, and then share them back with a provider. Of course it is still up to a provider to decide on what they accept, but there is not better way to make suggestions than a machine readable API definition, that is ready to go.

When I get around to doing some housecleaning on these API designs I generated, and possibly make some design iterations, I’ll focus on some of the smaller operations, leaving the bigger teams to do their own heavy lifting. Also, my goal isn’t just to iterate on API designs to help the original provider improve on their design, my goal is to iterative and improve on the API designs in my stack. The more designs I play with, more designs I have in my library, and the more I get a feel for what I think API designs could, or should look like.

I can’t fix all the APIs in the world, but I can improve on the hard work that has already occurred, and who knows, maybe some providers will see it for the compliment that it is, and listen to some of my API designing that is occurring out loud.