Developing Small, Simple, Meaningful Tools That Make An Impact Across The API Space

23 Feb 2015

I have API tooling on the brain, a result of conversations on multiple fronts, and the evolution of my own thoughts on creating what I’d see as the perfect API design tool. My thoughts on API tooling, reflect my general API philosophy, and focus on developing small, meaningful tools that truly make an impact.

First, nobody likes being dependent on bloated software products. The age where software looks like Microsoft Office in my opinion, is over, and I’m looking forward to a brighter future. I feel pretty strongly that we need small, simple tools, that work in concert, not via a single client I have to pay for 100% of features, to get just 2% of the features I actually need to get done, what I need.

One of my popular Github repositories is my CSV Converter, which is just a reworking of Mr. Data Converter, to which I added the ability to save XML, JSON, and CSV files directly to Github, making a completely client-side data management tool that runs 100% on Github pages. I like this idea developing small, stand-alone tooling for the API space, and is something you will see a lot more from me in coming months.

As I work to refine, and evolve my thoughts on the perfect API designer, I’m engaged in several conversations, about what the tooling could look like to support this vision, and the consensus seems to be that the next generation of tooling has to reflect an API philosophy—simple, small, stand-alone tools that do one thing and do it well. Something you can see this in popular API tooling like APITools, and Postman.

In recent times, I have been very adverse to developing any web or mobile client that someone else will depend on, stemming form PTSD developed by owning so much legacy code over my 25 year career. I'm happy to see that it isn’t just me, and that there are so many other souls out there who are tired of legacy software bloat, and ultimately becoming slave to this, from both a provider, and end-user perspective.

The moral of this story (for me), is that any client I build from here forward will be simple, small, and add real value to my operations, or it will be tossed. This approach reflects the way I see APIs, and if a service, or its resulting clients are not delivering value, they shouldn’t exist—something that isn’t possible, if you don’t have a modular, bite-size approach to developing your technology solutions. I'm fortunate...