The menu analogy is closer to the documentation for an API.
It might be easier to think of a more practical example like a smart light bulb. In this case, we’re talking about the types of bulbs that you can control with a phone app or smart speaker.
This light bulb is going to have a set of commands you can send to it. For the sake of this example, we’re going to skip over the part of how to connect to the bulb via Wi-Fi, Bluetooth or whatever proprietary radio system it uses. That’s all a discussion for a different question.
You could send “Set_Power(on)” to turn it on or “Set_Power(off)” to turn it off. You could also send stuff like “Set_Color(red)” or “Set_Brightness(50)” to change color and brightness, respectively.
It’s also possible to send commands that get information back. So something like “Get_Power()” would get it to respond whether or not it’s on. Similarly, you could also run “Get_Color()” or “Get_Brightness()” and get the respective statuses. If the smart bulb is especially smart, it may even support commands like “Get_Power_Usage()” that might return a whole table of dates, times and power consumption.
That set of commands and the responses they can create is the API for this light bulb.
If you wanted to write a program to control the bulb yourself, the API would be the vocabulary your program could use to talk to or listen to the smart bulb.
Latest Answers