04 Aug 2016
I was reading some of the blog posts, Reddit and Hacker News threads about Microsoft's release of their API design guid e. While many of the comments are technically correct, the tone in which they are delivered, and the intent behind their delivery is one of the biggest contributing factors to why we have such wild inconsistencies in API design across the landscape.
API Evangelist was born in 2010 out of frustration with the Restafarian pundit class. I made it my mission to help tell stories of the technical, business, and politics of APIs in an inclusive way, that didn't make people feel stupid for what they didn't understand. Even after six years of doing this, I am still learning things about APIs and being regularly reminded that there are few absolutes when it comes API design, definition, deployment, management, or any of the other 50+ stops along the API life cycle that I track on .
I stopped sharing my blog posts to Hacker News, Reddit, and DZone (reversed after they invested in change) because of hostile responses to my thoughts. I cannot imagine what it is like to work hard on your API design strategy at a company, then share publicly, only to get flamed because it wasn't REST compliant. Many folks will never even attempt this for fear of being flamed, and those that do, will often never make the mistake twice.
This is the opposite of what we want. We want EVERYONE organizing, publishing, and sharing their API design patterns so that we can all learn from each other. We don't want to make people feel stupid for what they do not know. We want to encourage everyone to learn, grow, evolve, and build on each other's design patterns and work from across the API sector.
Let's work to encourage more companies to craft, publish, and share their API design patterns. Let's please stop REST shaming folks, it didn't work in 2010, and it doesn't work in 2016. Making people feel dumb will never get us to a place where API developers and architects are truly HTTP literate, and well informed of existing patterns, let alone actually putting them to work across their organizations.