I read a lot of content about APIs. I read a lot of redundant and fluffy marketing and technical jargon, trying to understand exactly what an API does, or doesn't do. Before I criticize, I have to admit that crafting really good API marketing and documentation is hard. Only about 5% of what I read is good, a significant portion is just incomplete and lazily done by someone who doesn't care--the rest is actually incorrect, misleading, and straight up hype.
There are three layers to the API hype onion in my experience:
- Marketing - The fluff on the main page written by the marketing team who usually doesn't care about the API and has taken the time to get to know what it does.
- Documentation - The technical fluff in the API portal usually written by someone technical, and not quite possessing the skills to talk to humans, let alone coherently explain something to another human being.
- API - The actual naming, ordering, parameters, and overall request and response structure for an API that actually accomplishes something--it may not always accomplish exactly what I'm looking for, but at least it is.
While I still read marketing and documentation, because they provide me with clues about the intent behind API operations, when I actually want the honest take of what an API does, I always go straight to the API and get to work making API calls. This is a problem that is only increasing as we enter into the artificial intelligence and machine learning hype phase.
After you finish writing the marketing, documentation, and have your API up and running--step back, and re-read everything, and think about the synchronicity between these three areas of your operations. It takes a lot of practice and hard work to do right, but I think if you just take a moment, step back, and think about these layers to how you articulate what your APIs does--you will immediately find yourself in a better position to communicate what it is you are trying to accomplish to a much wider audience.
