I began exploring the use a restaurant menu to help people understand API copyright, and how your API definition is not your secret sauce, and that there is so much more to your API that just the surface area.
I'm continuing my exploration of using restaurants as an analogy to help onboard people with not just API copyright, but introducing APIs to the masses--helping them understand the layers to the API space, in a way that is familiar.
To prepare for future stories and conversations I'm expanding on my API definition = Menu analogy with:
- API Providers = Restaurant Owners
- Developer Portal = Restaurant
- APIs = Food & Drink Items
- API Definition + Docs = Menu
- API Consumers (Apps) = Restaurant Customers (People)
- Freemium - Samples Out Front
- Partner Access = Catering
- Terms of Service = We Reserve The Right To Refuse - No Substitutions
- API Service Providers = Restaurant Equipment Providers
Obviously it is work in progress. I will need better stories and visuals to get the concept across. Then once I start working through the different types of restaurants (ie. American, Chinese, Mexican, Fusion, etc), I'm sure I'll flush out more, while also potentially hitting some dead ends.
Explaining what an API is, let alone the versatility and flexibility of an API, is really hard. I need as many tools in my API toolbox to help get people up to speed, understanding what an API is, and how it can apply to their business. We'll see where I go with the restaurant analogy, who knows it might be a dead end. It proved to be extremeley valuable in helping people understand API copyright, and I'm hopefull it will do the same for APIs in general.
Let me know your thoughts...