As you mention in your comments below, stick with just API:s. A lot of companies are talking about API:s these days, but what they most likely mean are web API:s (and in most cases public web API:s), perhaps it's worth talking about this distinction. Also break API down into its parts and make it clear what each letter stands for and means. Some of my non-tech friends usually don't know what is meant by an "interface", let alone an application programming interface.
Try to find analogies to real world concepts and situations everyone can relate to regardless of background (your bridge analogy is a great example). Analogies are a great bridge (!) for understanding.
If you are going to demo something keep it as simple as possible (judging from what you write about your audience) and try to use something they can relate to or is really easy to get started with. For example Wikipedia's API and a simple web browser, and also provide examples of how another service could leverage Wikipedia (a travel app that gives you destination descriptions from Wikipedia?).
If you want to do something more tech than that the below are increasing levels of difficulty:
invoke Wikipedia's API using Postman
invoke Wikipedia's API using JavaScript from the browser console
Rasmus, thanks for your comment! Glad you like my analogy with bridges. I agree with you, analogies are a good way to simplify understanding of what for others could seem abstract concepts.
One would argue that a bridge analogy points towards point-to-point integrations, however, I don't expect that to happen with a not very technical audience :-)
I've been working with APIs (not web APIs though) for a few years now, never crossed my mind to look into the Wikipedia APIs. Definitely a must check!
As soon as I will know more about the attending group, I'll decide on the right technical level for the talk and depending on that I might go for some of the other tips you shared. Stay tuned!
Agreed, when I first started I was very confused by what an API actually was. I would definitely provide at least 3 different examples in addition to spelling out the acronym. At the simplest level, a function could be used as a pseudo-example of an API and build from there. At least it helped me to think of it that way. Now I see pretty much everything as an API.
Thanks, Elijah! This time I will most likely not go much into detail around functions (it will be too technical for the audience). Interesting suggestion to look at a function as a pseudo-example of an API. Similarly one could see an APIs resource as a function, meaning that the API can have multiple functions.
Indeed everything is interconnected and the simplest/ideal way to do that nowadays is via an API or via an interface. There's one analogy for interfaces / APIs that I recently received as an example from a colleague that I find very easy for anyone to relate to: our own biological interfaces with the world, ie our senses.
Elijah, small clarification: my above comment on API resources as functions makes sense in the context of REST APIs. The simplification you mentioned is totally legit!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As you mention in your comments below, stick with just API:s. A lot of companies are talking about API:s these days, but what they most likely mean are web API:s (and in most cases public web API:s), perhaps it's worth talking about this distinction. Also break API down into its parts and make it clear what each letter stands for and means. Some of my non-tech friends usually don't know what is meant by an "interface", let alone an application programming interface.
Try to find analogies to real world concepts and situations everyone can relate to regardless of background (your bridge analogy is a great example). Analogies are a great bridge (!) for understanding.
If you are going to demo something keep it as simple as possible (judging from what you write about your audience) and try to use something they can relate to or is really easy to get started with. For example Wikipedia's API and a simple web browser, and also provide examples of how another service could leverage Wikipedia (a travel app that gives you destination descriptions from Wikipedia?).
If you want to do something more tech than that the below are increasing levels of difficulty:
Rasmus, thanks for your comment! Glad you like my analogy with bridges. I agree with you, analogies are a good way to simplify understanding of what for others could seem abstract concepts.
One would argue that a bridge analogy points towards point-to-point integrations, however, I don't expect that to happen with a not very technical audience :-)
I've been working with APIs (not web APIs though) for a few years now, never crossed my mind to look into the Wikipedia APIs. Definitely a must check!
As soon as I will know more about the attending group, I'll decide on the right technical level for the talk and depending on that I might go for some of the other tips you shared. Stay tuned!
Agreed, when I first started I was very confused by what an API actually was. I would definitely provide at least 3 different examples in addition to spelling out the acronym. At the simplest level, a function could be used as a pseudo-example of an API and build from there. At least it helped me to think of it that way. Now I see pretty much everything as an API.
Thanks, Elijah! This time I will most likely not go much into detail around functions (it will be too technical for the audience). Interesting suggestion to look at a function as a pseudo-example of an API. Similarly one could see an APIs resource as a function, meaning that the API can have multiple functions.
Indeed everything is interconnected and the simplest/ideal way to do that nowadays is via an API or via an interface. There's one analogy for interfaces / APIs that I recently received as an example from a colleague that I find very easy for anyone to relate to: our own biological interfaces with the world, ie our senses.
Elijah, small clarification: my above comment on API resources as functions makes sense in the context of REST APIs. The simplification you mentioned is totally legit!