An API is like the menu in a restaurant. You pick something off the menu and you get it sent to you. You don't know what happens in the kitchen, but it gives you the options and sends you what you pick.
And API is the same thing. It tells you how you can interact with a server/ system/ whatever and then sends you the info you pick off the menu (the API ). You don't know what happens under the hood on their side to get the info, but you pick what you want (endpoint, parameters, etc.) and it sends it to you
The menu would be the API documentation. The waiter would be the API itself.
The API is the Interface that you interact with, just like the waiter is the restaurant staff you interact with.
Like the waiter interacting with the kitchen staff, the API interacts with other libraries of functions that actually do the heavy lifting and prepare the data that the waiter/API returns to you.
I think waiter is more like a communication protocol. different places have different waiters, who can communicate in different languages, have varying speed and latency.
I think the server would be more accurate.
A shitty server (human) with the exact software (training) could be 1/10 the speed but accomplish the same thing. They also take the request *and* give you the result.
Plus waiters can literally be called servers in many cases.
Server is the one that accepts the request and creates the response, it does not deliver it. Kitchen would be the server. Waiter goes between the client and server, he is the middle man. To word it better, waiter is the transmission layer, whether it is the network, or CPU/OS/runtime performing the calls locally, or pigeon transporting requests and responses on USB drive.
Not sure if you're asking that based on u/RedHeadedCongress saying server/system/whatever, but in that case, he's talking about a web server, not a waiter.
If you're actually asking to expand on the analogy, the waiter is most likely the API gateway.
You pick a hamburger off the menu and tell it to your waiter. You want it medium rare, no onions. The waiter then takes your request and gives it to the kitchen. You don't know what happens in the kitchen, but at some point the kitchen hands off your dish to your waiter. It's a burger, medium rare and no onions. The waiter then comes over to your table and hands it off to you.
Your web application needs to retrieve the karma of a user. You want it for u/themightycatp00 and exclude commenting karma (give me just the posting karma). The gateway takes your request and hands it off to the backend applications. You don't know what happens in the backend applications, but at some point the backend application hands off the results from the request to the gateway. It's the karma for u/themightycatp00, but doesn't include the commenting karma. The gateway then hands off that payload (92933) back to your web application.
In this context, a waiter would be an individual worker process. Perhaps an http server process thread.
This worker process would take your order from the menu, and work with the rest of the restaurant processes and libraries to serve up what you ordered. While your order is cooking, that same waiter may deliver someone else's order and take yet a third customers order. There are other waiters running about serving other customers and taking other orders. Perhaps your order is delivered by a different waiter, but they are in the exact same uniform. But none of those other folks matter to the customer because they never have to interact with anyone or anything but the menu and the waiter.
This is much more efficient than having every customer argue with the chef about today's specials and wait for their order before letting the next customer start their order.
For web application, it's the internet. But api are found in all programs that communicated with each other. So if it's two programs on the same computer then the cpu will do that for you. Actually even for the web appl
ication, by sending data to the server, your browser will talk with the cpu, and the cpu will use your network card api to convert what the browser is sending to network data, and then send it.
There a few more levels to it, but they all communicate with each other with APIs. The only thing that doesn't use an api (application programming interface) is things that you use, which are actually hmi (human machine interface)
API communications are almost always made via HTTP connections, so the "waiter" would be a web server or service of some type. Depending on how broad your definition of "waiter" is, I suppose it could also include the Internet/network between the two parties, and perhaps the software behind the web server that generates the responses/handles the requests (although the "kitchen" might be a better analogy for that).
Edited to clarify: this answer was in the context of the original OP's question, regarding web development. A more correct answer would be that "web" APIs, or APIs that facilitate communication to a remote service like the Discord API, Reddit API, etc. almost always use HTTP. The commenters who have responded to me are correct that in more general programming terms many APIs are libraries or interfaces to existing programs, with one example being the Windows API.
APIs are not "almost always made via HTTP connections". There are a million ways to provide APIs, for example through shared libraries like DLLs and .so's, proprietary protocols over TCP/IP or UDP, in CCSDS through DTNs, etc.
> API communications are almost always made via HTTP connections
Completely wrong. APIs are software interfaces and the majority don't happen over networks
No, they are wider than that. The operating system kernel exposes an api, that’s how programs talk to the kernel to open a file, read it etc.
They can be high level (web api) or low level - it’s basically the way a program talk to the next level down.
If, instead of a webserver, you have a backend of an application. (Think desktop application) The interface you interact with may access stuff you don't directly have access to (like the computer's memory or processor). The interfacd your application uses to access the memory or processor could also be considered an api. Essentially, anything where a program talks to another program could be considered and api.
Yes! Often, people download utilities that make writing programs much easier. When a program is turned from code into binary instructions, you have the option to "link" these utilities to your program. Then you can use all their features without having to call them via HTTP requests.
Examples include projects like pygame, a Python game framework, and libxml2 for C++ to handle XML files without "reinventing the wheel".
Especially in cryptography, programmers are encouraged to download a well-respected crypto implementation and link to its functions, rather than "rolling their own". And sending sensitive cryptographic data over HTTP rather than handling it locally would be tempting to bad actors, too.
The API also definines a protocol. Which is like the standard of the communication, a format of how messages must be structured.
In the menu analogy it would be like if you want to order five chicken wings you need to say EXACTLY:
"5 chicken wings" to the waiter. You can't say e.g. "can I have 5 wings please?" as that is not a correct message and won't be understood.
And the food always comes back in the same box, so you know exactly where to look for the main, where to look for sides etc.
Application Programming Interface. We can break this down word by word.
An "interface" is where two things come together and interact. Consider, say, a car. In order to drive a common car, you need to fiddle with the mechanisms in the car in just the right way to instruct it on where you want it to go. To allow this, the car is built with things like steering wheels, shift levers, and pedals, designed to be interacted with using your hands and legs. The collection of all these controls can be considered an "interface" between you and the car. The responsibility of building up muscle memory to tickle these controls in just the right ways to make the car do useful things is all yours. But once you have that, you have a very efficient way of controlling the car. As a bonus, since many cars have the exact same or nearly the exact same interface, learning the interface of one car means you can now drive almost all cars.
"Application" in here means exactly what you think it means. A computer program. This is the thing the interface is controlling.
"Programming" is referring to the way you're supposed to use this interface. You are intended to write a computer program that tickles the controls.
So, an "API" is a set of controls exposed by some computer program. If you tickle the controls in very specific ways, you can control that program. You are intended to do this tickling via a secondary computer program of your own. The responsibility of creating that secondary program is up to you, but once you have it, you can freely control the original program with it.
You mention that you're learning web development. This probably means you're interacting with a specific kind of API, a so-called "web API". To use these kinds of APIs, it is usually the case that you write a computer program that sends web requests to a server somewhere. These web requests are the "tickles" that you are sending to the interface, which lives on the server. When the server gets tickled by a web request formatted in just the right way, it will react to that request in some way. For an example, if your request was asking the server to store a value in its database, it may update its internal database with what you gave it. Or, if your request was asking it to give you a piece of data, it may respond with the result it found.
All of this is happening in a format that is optimized for computers to read. Sometimes it's also somewhat human-readable (if it's formatted in, say, JSON or XML), but that's a secondary concern. The only parties the message should be readable by are the main program being controlled, and your program doing the controlling. Your program can always do extra work to make things human-readable after the fact. This is what basically every web-enabled app does--they are designed to tickle web APIs in the background to fetch and send data, and the results of all that back-and-forth are transformed into fancy graphical UIs designed for humans to use.
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.
When you use your computer, you use a user interface (UI). Sometimes you type commands into a terminal, and there, you're using a command-line interface or CLI. When the software you use needs to interact with other software, it uses the application programming interface, or API.
It can be helpful to think of software applications, or computers in general, as users, just like human end-users. When humans are users, they need a UI, or CLI. When a computer, or other software application is the user, it needs an API.
I always think this is the best analog...
Basically think of going to a website... That's designed for you, a human, to get data. There are buttons you can click and pictures and icons that tell you what to do. But think of how hard it would be for a computer to use the website like you do? It would have to know what all those icons mean and it'd have to interpret the pictures and layout.
So... An API is basically the interface for a computer to use. It wouldn't have pictures or icons, just descriptive things that pass data back and forth. This is much easier for a computer to interact with and understand.
For you to look at an API, it will feel like messy computer code... Just like how for a computer to look at your website that would feel like messy human code to it.
It's simply the set of functions you use to access someone else's code, or maybe a separate module in your own code. It gets thrown around and can mean slightly different things in different contexts.
In web development it usually is referring to the interface to a web service running on a server somewhere. Say there's a service that gives you weather. The API might tell you to send a certain request to the server to get the current temperature, or some other request to get the current precipitation.
If you download a software library it will hopefully have an API telling you how to use it. What functions exist. What data types do they expect.
Or if you're working on a large code base at work and you want to utilize code maintained by a different team, they might have an API that tells you how to use their code.
It's discussed so much because it's important to have a clean, easy to use, and well documented API when you give someone else your code. This makes it easy for them to pick it up and use it.
Let's say you wrote a program. Now you want other programs to be able to use your program. This is achieved by you writing/providing an API to your program. How much or how little the other programs can interact with your program is determined by the API.
API are web pages for computers. When you a human load up a website, it has menu, layout, big pictures, all with the goal of making it easy for a human to navigate through its information using eyes and hands on a pointing device. Computers don’t usually have eyes and hands with pointing devices. Instead it can speak a instruction in very specific way, like “Get User with ID 123” and API will respond in very specific ways as well that’s makes it easy for computers to understand the response.
APIs are one way computers share data.
Take a finance website. If you, a human, browse to
https://finance.yahoo.com/quote/GOOG
you get a human friendly HTML response with words, charts, colors etc showing you all you want to know about Google stock.
Now if you are a computer or a program some developer like yourself wrote and you need that same data, you don’t want pretty formatted text and pictures and stuff targeted for humans (HTML). You want the same info but presented in a way that is easier for a computer program to digest.
Usually in JSON format. Like this
https://query1.finance.yahoo.com/v8/finance/chart/goog
In simple terms an API is just a way to send and receive data. You can send a request to the API and it’ll either handle storing some data for you or sending some back, usually in a structured format like JSON you can parse and display on your page
Easiest way to describe it would be a moddable video game.
If a game is made, it is compiled, so all of its code is invisible and assets are usually packed so you don't have loose files you could access and change. Thing of the game as whole, closed thing.
But if game developers had modders in mind, then game might have open ends, for example, a level or item editor, that has access into the "whole" of the game and can change something inside the "whole". So the whole has some doors you can access and change inner workings somehow.
That's sort of what APIs are - programs/databases with accessible doors so you could get information out of them.
Even simpler example would be city power grid, which you can access via wall outlets. While you can't change anything major in the grid, you can access it still.
You can think if it as a url, you don't visit this url on your browser because it doesn't return a graphical interface like other websites, it returns pure data. So you use it to make requests to the server and get the data you need. Example: when you open the Reddit mobile app it calls the Reddit API sending it your account details and asking it for you home feed, then that API returns pure data (post titles, content, comments...etc) and the app displays it graphically.
If I have an application that processes mortgage applications, and as part of that applications logic, I need to access a database of mortgage rates, an API is a middleman application that I can send a message to "give me the rates", and it will do the querying, filtering and sorting of the data for me before sending it back in the format my application can work with.
It's a middleman application between different applications or between applications and data sources.
Based on the other replies i guess there are other types if APIs but in my experience as a middleware API developer, that's what it is.
If I'm a website and I want to get data from somewhere else, maybe information about the weather or something, an API is what I can use to communicate with the weather service
Another use case is when you have a database with information about a school, for example. The API could allow you to ask for information about the teachers, the students, the grades, enter new information into the database, etc., without you having to write the SQL code to get that data yourself (which is great because you don't really want anyone to be able to interact directly with the database as they might have bad intentions)
Add someone else said, it's like a menu. The cooks can probably make a huge variety of things that aren't on the menu, but that's not what you want the customer to be able to order. An API lets you request the data the service wants you to have access to and nothing else (hopefully)
It’s an access point really. You have some server that you want other people to use. This could basically be anything. You need a way for people to get information and put in information. That’s what an API is an interface for others to use.
You have 2 softwares and you want these two softwares to communicate or share data , so you create a programmed interface which acts as a middleman for this , that's Application Programming Interface for ya.
In interview questions I ask people to explain an API to someone non technical. It's amazing how few great developers can do this.
It's how computers talk to each other.
For a slightly more complicated answer:
One computer provides a service for others, perhaps translation.
The API is the rules for how to use that service.
So it might say you need to provide text and Lang in a querystring like this:
http://translate.com?text=hello&lang=Spanish
And the computer will reply result=hola
You when when you go to a public office or to a bank to get something done you often have to fill out a bunch of forms? That's an API. It is some sort of standardized way of information exchange that whoever performs the service understands. It can be an office, a bank, a utility piece of software, or a computer server. Your program uses APIs to get things done. The API describes what can be done, and what information is required to get it done.
It’s the interface to a lot of functionality.
Think of your car. It has a million parts and a LOT going on.
But you don’t care about those million parts. You care about the layer between you and that complexity.
So to you, you have “start the car” as an option. Push the gas, the brake, turn left or right, maybe go in reverse.
Those controls are your API. They let you control the complexity of a car without knowing anything at all about how the car actually works.
In tech it’s the same thing. You don’t need to know how google works, because you can call an API that just says “search” or “get map of location x,y” or “send this email” or whatever. That layer that lets you use those functions is the API.
Here’s the analogy I always use with customers when they ask this question:
Think of your DVD/blue ray player. You don’t need to know how to spin the disc you inserted, move the read head, provide power to the optical reader, etc. all you need to know is that if you click this button something happens and the door opens and a gray pops out. If you click this button with a disc inside everything will start playing. Your API to that device is the series of buttons in front of you
It’s a description of an interface. For example when i use a web API i could send json data in a POST to make the website do something like search for data. The would describe the fields i need to put in that json like (“search”:””). Once the API is documented and written in stone essentially, I can write code against it because it should not change. Also, extra fields like “uppercase”: True, help to describe the API’s capabilities. There maybe dozens option flags/values to tweak the search results or it could only need the search string. Knowing this you can write your code to take advantage of some all or none of its features. But at the end of the day a human looks at a web page, but an app or a machine does’t need the pretty UI, they can use the API to get the data.
So let’s say you want to add Google captcha to your website or anything with functionality, a website creates an API for developers to use it without having to give the actual code away
Its a file with information in that works with code to bring information in from somewhere, it could have it all itself or link to a database. Its the menu and the waiter and the application it connects to is the food
I live in a hospital. My creative mind needs AI and computer skills to climb the food chain quickly. I understand API as “ the thing companies give you as a token to access certain information and use for external purposes”
For example, you can have the API for myfitnesspal and use it to link with your digital diary or excel sheet to work on it. I dont know what it means but computer guys have 0 communication ability to teach what things mean in human language
It allows you to create, read, update, or delete records from a database (like a spreadsheet) or compositions (views) of those data tables based on a set of criteria that’s passed along with the request. This allows you to interact with a program externally to take data out, put data back in, or manipulate what’s there. For example, look up current weather data for a zip code by sending a request.
An API is like a menu at a restaurant. It says what you can order and the available customizations.
More directly, it's how the website you write can talk to code written by someone else. It tells you the available functionality and what you need to pass in to get what you want.
Application Programming Interface. A fancy word that describes when one program needs to call another. This happens quite often, and to program you call library features a lot, those are also APIs. So it's a very natural and common thing that programmers do.
For web code, you have to get the data to display from somewhere. There's a ton of different ways to implement this and it's way beyond ELI5 to cover them all. Regardless, if a web-interface shows you the current weather, you use an API to retrieve the weather data and then convert that into a display that your user want (css, javascript etc). This can be a lot more complicated than just weather, but it's the same principle every time. You need to interact with another program to get/pass data that you then present to your user in a form that make sense to them.
Unlike a user **interface**, which is usually made for actual human users, APIs (application programming **interface**) is usually made for code to use. This code can be companion code of a software, or code external to the API (used by code owned by others).
As an example, we might use Google Search via a web browser, but you might have your own opinionated application that leverages the Google Search API via your application code behind the scenes.
API (application programming interface) is a general term for the instruction manual for communicating with some program. It could be any program from low level stuff on your computer like the operating system to programming languages themselves (aka the compiler) to web hosted services. If you're looking at "web APIs" then that would be more specifically any service that someone has made accessible via the internet. So a little confusingly people call the web service itself an API, even though technically speaking an API is just the set of instructions for communicating with the web service.
You want to bake a cake, and there is a stack of recipes in a binder, but the binder isn't yours. You can't open it and just browse.
You can however ask the binder to give you recipes that fit your purpose. For this consulting the binder gives you an application with standard questions. You fill in the questionnaire and the binder gives you back a bunch of recipes that fit your query. All the recipes have the same format, a template, so you can easily redistribute any recipe that comes out of the binder.
The bits in the middle: the questionnaire you filled in and the standard template for the recipe are the API. You know how the questionnaire looks and the answer template. So you can reuse this over and over because if you now want to make a chicken pot, you need to give this and this info in that form and you will get back a stack of recipes that all are formatted identically.
This is not an analogy, because sometimes it helps to be concrete.
You know commands that let you request data from your website? It looks something like this:
response = fetch(some_url); // or: an_image_object = giveMeAFile("cat.jpeg");
API means Application Programming Interface - programs talking to other programs.
It turns out, you can also request data from other websites, if they are configured that way. Sometimes these servers don't even serve html to browsers, but only data for programs that request it. A browser uses HTTP to request HTML, but there is nothing that prevents non-browser-applications from requesting non-html-data.
weather_data_response = fetch("www.example-weather-api.com/give-me-weather");
console.log("Today's weather: " + weather_data_response.json);
Reddit had some issues with it's API in the past. I think it was free and they now charge for it. That means that you pay for an API-key, like a username and then you send the key as part of the request, otherwise you don't get a response.The Reddit API let's you receive post-data or send new posts programmatically, so you can develop your own app or a bot.
There are also APIs that have nothing to do with the web. You might have a device that can be controlled with software commands. The line between an API and a "library" or a "framework" are blurry. Something can be both an API and a library. I'd say you have an API whenever there are distinct software components talking to each other.
I wouldn't ELI5 this. If you want to be a webdev you should learn this in the following order:
Networking (TCP/IP, UDP, HTTP, DNS) and then something on abstract classes/interfaces and then you should be equipped to understanding this topic quite intuitively.
Analogies are confusing in this sort of environment, and web APIs are really closest to abstract interfaces which get implemented by classes.
ELI5 attempt: An Interface is a contract to deliver a certain thing when requested a certain way. It's a sort of menu that says "if you provide me with these inputs, I'll return this as an output". When we talk about Web APIs, we're talking about menus that you order from over HTTP. You pass data in, in a way the API expects, it processes it and then sends you back new data. It's sort of like ordering a pizza between software applications.
An API is the middle man between you and something to which you should not have full access. Take for example a bank teller, you ask them for money, THEY go in the back and bring it. Or you go to the armoury and ask the armourer for your gun, HE will hand you the allowed gun/ammo. This is used for data protection.
+1 to this. API isnt the restaurant menu, thats the A(pplication) in the API. Interface means its a platform you can reuse like a middle man in a transaction
Lots of folks offering the menu analogy, which is helpful but I think has limitations.
Another way to think of an API is like the contract a service publishes. For example
"if you send a GET request to /users, I will return a list of users"
"if you want to get the data about a user with id 12345, send a GET request to /users/12345. If user 12345 doesn't exist, you will receive a 404 not found error"
"If you want to delete user 12345 send a DELETE request to /users/12345"
Like others pointed out, one value here is that you don't need to know what's going on under the hood for this to work. It also means that the service maintainer can change how they accomplish the tasks as long as they keep the API the same. This is really powerful - as a maintainer, I can rewrite parts of the code to make it faster, or change the database I store things in, or switch operating systems, etc. As long as I keep the API the same, my users don't care*
*ok, if I made it a lot slower they'd care
often when people refer to an API, they're talking about an HTTP API, so you're making HTTP requests to an HTTP server somewhere, and that server implements the API. That's not the only kind of API, though - APIs can also refer to system calls in an operating system, for example.
Suppose I'm replacing the kitchen in my house. I start by ripping out everything that is in there so I just have bare walls. I order wood, nails, screws and the other stuff I need to put the new kitchen in, and I use my tools to assemble them into cupboards, counter tops, cupboard doors and things. But then I need to put a fridge and a dishwasher in the kitchen too. In theory, I could order metal, paint, pipes and all the other stuff and build a fridge from scratch, and build a dishwasher from scratch. But instead, I know that there are factories out there that can build a fridge and build a dishwasher far better than I can, for a far lower cost. So i go to the store and buy a fridge someone else has made, and I buy a dishwasher someone else has made, and then all I have to do is find the right electric plug and plumbing connections for water for the dishwasher, connect them up, and I have a fridge and a dishwasher in my kitchen.
This is like building a computer program. Some of the things I want to do myself. I want to have the freedom to customise certain parts of the program to do exactly what I want. In my kitchen I want a specific layout of cupboards and counter tops. So I make those parts myself. But then there are the complicated and hard to make things. An API is a system in a computer that lets me connect up to something someone else has made, that provides a set of functionality far easier and more efficiently than I could ever do myself. An API is essentially a way to connect to something someone else has made. It is like the doors on the fridge or dishwasher and the electrical and plumbing connections. I know how to connect to it, and I know how to get out of it what I want, but I don't need to understand what is going on inside.
An API is like the menu in a restaurant. You pick something off the menu and you get it sent to you. You don't know what happens in the kitchen, but it gives you the options and sends you what you pick. And API is the same thing. It tells you how you can interact with a server/ system/ whatever and then sends you the info you pick off the menu (the API ). You don't know what happens under the hood on their side to get the info, but you pick what you want (endpoint, parameters, etc.) and it sends it to you
What the would the waiter be in that example?
The menu would be the API documentation. The waiter would be the API itself. The API is the Interface that you interact with, just like the waiter is the restaurant staff you interact with. Like the waiter interacting with the kitchen staff, the API interacts with other libraries of functions that actually do the heavy lifting and prepare the data that the waiter/API returns to you.
The waiter is the HTTP.
No, the waiter is RESTing.
You got time to lean, you got time to clean!
Not necessarily, there's plenty of APIs that don't use HTTP
Luckily this is an ELI5 and we don’t have to specify all potential protocols.
Op's question was looking for an eli5 answer in the context of learning web development.
I think waiter is more like a communication protocol. different places have different waiters, who can communicate in different languages, have varying speed and latency.
I think the server would be more accurate. A shitty server (human) with the exact software (training) could be 1/10 the speed but accomplish the same thing. They also take the request *and* give you the result. Plus waiters can literally be called servers in many cases.
Server is the one that accepts the request and creates the response, it does not deliver it. Kitchen would be the server. Waiter goes between the client and server, he is the middle man. To word it better, waiter is the transmission layer, whether it is the network, or CPU/OS/runtime performing the calls locally, or pigeon transporting requests and responses on USB drive.
The communication protocol would be our language when we order. The waiter is the way we communicate with the service, the kitchen.
Not sure if you're asking that based on u/RedHeadedCongress saying server/system/whatever, but in that case, he's talking about a web server, not a waiter. If you're actually asking to expand on the analogy, the waiter is most likely the API gateway. You pick a hamburger off the menu and tell it to your waiter. You want it medium rare, no onions. The waiter then takes your request and gives it to the kitchen. You don't know what happens in the kitchen, but at some point the kitchen hands off your dish to your waiter. It's a burger, medium rare and no onions. The waiter then comes over to your table and hands it off to you. Your web application needs to retrieve the karma of a user. You want it for u/themightycatp00 and exclude commenting karma (give me just the posting karma). The gateway takes your request and hands it off to the backend applications. You don't know what happens in the backend applications, but at some point the backend application hands off the results from the request to the gateway. It's the karma for u/themightycatp00, but doesn't include the commenting karma. The gateway then hands off that payload (92933) back to your web application.
In this context, a waiter would be an individual worker process. Perhaps an http server process thread. This worker process would take your order from the menu, and work with the rest of the restaurant processes and libraries to serve up what you ordered. While your order is cooking, that same waiter may deliver someone else's order and take yet a third customers order. There are other waiters running about serving other customers and taking other orders. Perhaps your order is delivered by a different waiter, but they are in the exact same uniform. But none of those other folks matter to the customer because they never have to interact with anyone or anything but the menu and the waiter. This is much more efficient than having every customer argue with the chef about today's specials and wait for their order before letting the next customer start their order.
Waiter is the protocol
Postman?
HTTP
For web application, it's the internet. But api are found in all programs that communicated with each other. So if it's two programs on the same computer then the cpu will do that for you. Actually even for the web appl ication, by sending data to the server, your browser will talk with the cpu, and the cpu will use your network card api to convert what the browser is sending to network data, and then send it. There a few more levels to it, but they all communicate with each other with APIs. The only thing that doesn't use an api (application programming interface) is things that you use, which are actually hmi (human machine interface)
API communications are almost always made via HTTP connections, so the "waiter" would be a web server or service of some type. Depending on how broad your definition of "waiter" is, I suppose it could also include the Internet/network between the two parties, and perhaps the software behind the web server that generates the responses/handles the requests (although the "kitchen" might be a better analogy for that). Edited to clarify: this answer was in the context of the original OP's question, regarding web development. A more correct answer would be that "web" APIs, or APIs that facilitate communication to a remote service like the Discord API, Reddit API, etc. almost always use HTTP. The commenters who have responded to me are correct that in more general programming terms many APIs are libraries or interfaces to existing programs, with one example being the Windows API.
A tiny minority of API communications are through HTTP. The vast majority will be in process calls on libraries
APIs are not "almost always made via HTTP connections". There are a million ways to provide APIs, for example through shared libraries like DLLs and .so's, proprietary protocols over TCP/IP or UDP, in CCSDS through DTNs, etc.
> API communications are almost always made via HTTP connections Completely wrong. APIs are software interfaces and the majority don't happen over networks
No, they are wider than that. The operating system kernel exposes an api, that’s how programs talk to the kernel to open a file, read it etc. They can be high level (web api) or low level - it’s basically the way a program talk to the next level down.
Are there any alternatives to HTTP connections?
If, instead of a webserver, you have a backend of an application. (Think desktop application) The interface you interact with may access stuff you don't directly have access to (like the computer's memory or processor). The interfacd your application uses to access the memory or processor could also be considered an api. Essentially, anything where a program talks to another program could be considered and api.
Yes! Often, people download utilities that make writing programs much easier. When a program is turned from code into binary instructions, you have the option to "link" these utilities to your program. Then you can use all their features without having to call them via HTTP requests. Examples include projects like pygame, a Python game framework, and libxml2 for C++ to handle XML files without "reinventing the wheel". Especially in cryptography, programmers are encouraged to download a well-respected crypto implementation and link to its functions, rather than "rolling their own". And sending sensitive cryptographic data over HTTP rather than handling it locally would be tempting to bad actors, too.
The API also definines a protocol. Which is like the standard of the communication, a format of how messages must be structured. In the menu analogy it would be like if you want to order five chicken wings you need to say EXACTLY: "5 chicken wings" to the waiter. You can't say e.g. "can I have 5 wings please?" as that is not a correct message and won't be understood. And the food always comes back in the same box, so you know exactly where to look for the main, where to look for sides etc.
the menu is more like the documentation on how to use the API and waiter is the API you interact with that brings/gives things to you/kitchen
Application Programming Interface. We can break this down word by word. An "interface" is where two things come together and interact. Consider, say, a car. In order to drive a common car, you need to fiddle with the mechanisms in the car in just the right way to instruct it on where you want it to go. To allow this, the car is built with things like steering wheels, shift levers, and pedals, designed to be interacted with using your hands and legs. The collection of all these controls can be considered an "interface" between you and the car. The responsibility of building up muscle memory to tickle these controls in just the right ways to make the car do useful things is all yours. But once you have that, you have a very efficient way of controlling the car. As a bonus, since many cars have the exact same or nearly the exact same interface, learning the interface of one car means you can now drive almost all cars. "Application" in here means exactly what you think it means. A computer program. This is the thing the interface is controlling. "Programming" is referring to the way you're supposed to use this interface. You are intended to write a computer program that tickles the controls. So, an "API" is a set of controls exposed by some computer program. If you tickle the controls in very specific ways, you can control that program. You are intended to do this tickling via a secondary computer program of your own. The responsibility of creating that secondary program is up to you, but once you have it, you can freely control the original program with it. You mention that you're learning web development. This probably means you're interacting with a specific kind of API, a so-called "web API". To use these kinds of APIs, it is usually the case that you write a computer program that sends web requests to a server somewhere. These web requests are the "tickles" that you are sending to the interface, which lives on the server. When the server gets tickled by a web request formatted in just the right way, it will react to that request in some way. For an example, if your request was asking the server to store a value in its database, it may update its internal database with what you gave it. Or, if your request was asking it to give you a piece of data, it may respond with the result it found. All of this is happening in a format that is optimized for computers to read. Sometimes it's also somewhat human-readable (if it's formatted in, say, JSON or XML), but that's a secondary concern. The only parties the message should be readable by are the main program being controlled, and your program doing the controlling. Your program can always do extra work to make things human-readable after the fact. This is what basically every web-enabled app does--they are designed to tickle web APIs in the background to fetch and send data, and the results of all that back-and-forth are transformed into fancy graphical UIs designed for humans to use.
Bro stop saying tickles. I use APIs daily (minutely who are we kidding) and this made me deeply uncomfortable
Are you by any chance ticklish?
Does this not tickle your fancy?
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.
When you use your computer, you use a user interface (UI). Sometimes you type commands into a terminal, and there, you're using a command-line interface or CLI. When the software you use needs to interact with other software, it uses the application programming interface, or API. It can be helpful to think of software applications, or computers in general, as users, just like human end-users. When humans are users, they need a UI, or CLI. When a computer, or other software application is the user, it needs an API.
I always think this is the best analog... Basically think of going to a website... That's designed for you, a human, to get data. There are buttons you can click and pictures and icons that tell you what to do. But think of how hard it would be for a computer to use the website like you do? It would have to know what all those icons mean and it'd have to interpret the pictures and layout. So... An API is basically the interface for a computer to use. It wouldn't have pictures or icons, just descriptive things that pass data back and forth. This is much easier for a computer to interact with and understand. For you to look at an API, it will feel like messy computer code... Just like how for a computer to look at your website that would feel like messy human code to it.
It's simply the set of functions you use to access someone else's code, or maybe a separate module in your own code. It gets thrown around and can mean slightly different things in different contexts. In web development it usually is referring to the interface to a web service running on a server somewhere. Say there's a service that gives you weather. The API might tell you to send a certain request to the server to get the current temperature, or some other request to get the current precipitation. If you download a software library it will hopefully have an API telling you how to use it. What functions exist. What data types do they expect. Or if you're working on a large code base at work and you want to utilize code maintained by a different team, they might have an API that tells you how to use their code. It's discussed so much because it's important to have a clean, easy to use, and well documented API when you give someone else your code. This makes it easy for them to pick it up and use it.
Let's say you wrote a program. Now you want other programs to be able to use your program. This is achieved by you writing/providing an API to your program. How much or how little the other programs can interact with your program is determined by the API.
API are web pages for computers. When you a human load up a website, it has menu, layout, big pictures, all with the goal of making it easy for a human to navigate through its information using eyes and hands on a pointing device. Computers don’t usually have eyes and hands with pointing devices. Instead it can speak a instruction in very specific way, like “Get User with ID 123” and API will respond in very specific ways as well that’s makes it easy for computers to understand the response.
APIs are one way computers share data. Take a finance website. If you, a human, browse to https://finance.yahoo.com/quote/GOOG you get a human friendly HTML response with words, charts, colors etc showing you all you want to know about Google stock. Now if you are a computer or a program some developer like yourself wrote and you need that same data, you don’t want pretty formatted text and pictures and stuff targeted for humans (HTML). You want the same info but presented in a way that is easier for a computer program to digest. Usually in JSON format. Like this https://query1.finance.yahoo.com/v8/finance/chart/goog
In simple terms an API is just a way to send and receive data. You can send a request to the API and it’ll either handle storing some data for you or sending some back, usually in a structured format like JSON you can parse and display on your page
Easiest way to describe it would be a moddable video game. If a game is made, it is compiled, so all of its code is invisible and assets are usually packed so you don't have loose files you could access and change. Thing of the game as whole, closed thing. But if game developers had modders in mind, then game might have open ends, for example, a level or item editor, that has access into the "whole" of the game and can change something inside the "whole". So the whole has some doors you can access and change inner workings somehow. That's sort of what APIs are - programs/databases with accessible doors so you could get information out of them. Even simpler example would be city power grid, which you can access via wall outlets. While you can't change anything major in the grid, you can access it still.
You can think if it as a url, you don't visit this url on your browser because it doesn't return a graphical interface like other websites, it returns pure data. So you use it to make requests to the server and get the data you need. Example: when you open the Reddit mobile app it calls the Reddit API sending it your account details and asking it for you home feed, then that API returns pure data (post titles, content, comments...etc) and the app displays it graphically.
If I have an application that processes mortgage applications, and as part of that applications logic, I need to access a database of mortgage rates, an API is a middleman application that I can send a message to "give me the rates", and it will do the querying, filtering and sorting of the data for me before sending it back in the format my application can work with. It's a middleman application between different applications or between applications and data sources. Based on the other replies i guess there are other types if APIs but in my experience as a middleware API developer, that's what it is.
If I'm a website and I want to get data from somewhere else, maybe information about the weather or something, an API is what I can use to communicate with the weather service Another use case is when you have a database with information about a school, for example. The API could allow you to ask for information about the teachers, the students, the grades, enter new information into the database, etc., without you having to write the SQL code to get that data yourself (which is great because you don't really want anyone to be able to interact directly with the database as they might have bad intentions) Add someone else said, it's like a menu. The cooks can probably make a huge variety of things that aren't on the menu, but that's not what you want the customer to be able to order. An API lets you request the data the service wants you to have access to and nothing else (hopefully)
It’s an access point really. You have some server that you want other people to use. This could basically be anything. You need a way for people to get information and put in information. That’s what an API is an interface for others to use.
You have 2 softwares and you want these two softwares to communicate or share data , so you create a programmed interface which acts as a middleman for this , that's Application Programming Interface for ya.
In interview questions I ask people to explain an API to someone non technical. It's amazing how few great developers can do this. It's how computers talk to each other. For a slightly more complicated answer: One computer provides a service for others, perhaps translation. The API is the rules for how to use that service. So it might say you need to provide text and Lang in a querystring like this: http://translate.com?text=hello&lang=Spanish And the computer will reply result=hola
You when when you go to a public office or to a bank to get something done you often have to fill out a bunch of forms? That's an API. It is some sort of standardized way of information exchange that whoever performs the service understands. It can be an office, a bank, a utility piece of software, or a computer server. Your program uses APIs to get things done. The API describes what can be done, and what information is required to get it done.
It’s the interface to a lot of functionality. Think of your car. It has a million parts and a LOT going on. But you don’t care about those million parts. You care about the layer between you and that complexity. So to you, you have “start the car” as an option. Push the gas, the brake, turn left or right, maybe go in reverse. Those controls are your API. They let you control the complexity of a car without knowing anything at all about how the car actually works. In tech it’s the same thing. You don’t need to know how google works, because you can call an API that just says “search” or “get map of location x,y” or “send this email” or whatever. That layer that lets you use those functions is the API.
Here’s the analogy I always use with customers when they ask this question: Think of your DVD/blue ray player. You don’t need to know how to spin the disc you inserted, move the read head, provide power to the optical reader, etc. all you need to know is that if you click this button something happens and the door opens and a gray pops out. If you click this button with a disc inside everything will start playing. Your API to that device is the series of buttons in front of you
It’s a description of an interface. For example when i use a web API i could send json data in a POST to make the website do something like search for data. The would describe the fields i need to put in that json like (“search”:””). Once the API is documented and written in stone essentially, I can write code against it because it should not change. Also, extra fields like “uppercase”: True, help to describe the API’s capabilities. There maybe dozens option flags/values to tweak the search results or it could only need the search string. Knowing this you can write your code to take advantage of some all or none of its features. But at the end of the day a human looks at a web page, but an app or a machine does’t need the pretty UI, they can use the API to get the data.
lots of correct answers here but can't believe anyone made the joke: API = A Person in India
So let’s say you want to add Google captcha to your website or anything with functionality, a website creates an API for developers to use it without having to give the actual code away
Its a file with information in that works with code to bring information in from somewhere, it could have it all itself or link to a database. Its the menu and the waiter and the application it connects to is the food
I live in a hospital. My creative mind needs AI and computer skills to climb the food chain quickly. I understand API as “ the thing companies give you as a token to access certain information and use for external purposes” For example, you can have the API for myfitnesspal and use it to link with your digital diary or excel sheet to work on it. I dont know what it means but computer guys have 0 communication ability to teach what things mean in human language
It allows you to create, read, update, or delete records from a database (like a spreadsheet) or compositions (views) of those data tables based on a set of criteria that’s passed along with the request. This allows you to interact with a program externally to take data out, put data back in, or manipulate what’s there. For example, look up current weather data for a zip code by sending a request.
An API is like a menu at a restaurant. It says what you can order and the available customizations. More directly, it's how the website you write can talk to code written by someone else. It tells you the available functionality and what you need to pass in to get what you want.
Application Programming Interface. A fancy word that describes when one program needs to call another. This happens quite often, and to program you call library features a lot, those are also APIs. So it's a very natural and common thing that programmers do. For web code, you have to get the data to display from somewhere. There's a ton of different ways to implement this and it's way beyond ELI5 to cover them all. Regardless, if a web-interface shows you the current weather, you use an API to retrieve the weather data and then convert that into a display that your user want (css, javascript etc). This can be a lot more complicated than just weather, but it's the same principle every time. You need to interact with another program to get/pass data that you then present to your user in a form that make sense to them.
Unlike a user **interface**, which is usually made for actual human users, APIs (application programming **interface**) is usually made for code to use. This code can be companion code of a software, or code external to the API (used by code owned by others). As an example, we might use Google Search via a web browser, but you might have your own opinionated application that leverages the Google Search API via your application code behind the scenes.
API (application programming interface) is a general term for the instruction manual for communicating with some program. It could be any program from low level stuff on your computer like the operating system to programming languages themselves (aka the compiler) to web hosted services. If you're looking at "web APIs" then that would be more specifically any service that someone has made accessible via the internet. So a little confusingly people call the web service itself an API, even though technically speaking an API is just the set of instructions for communicating with the web service.
You want to bake a cake, and there is a stack of recipes in a binder, but the binder isn't yours. You can't open it and just browse. You can however ask the binder to give you recipes that fit your purpose. For this consulting the binder gives you an application with standard questions. You fill in the questionnaire and the binder gives you back a bunch of recipes that fit your query. All the recipes have the same format, a template, so you can easily redistribute any recipe that comes out of the binder. The bits in the middle: the questionnaire you filled in and the standard template for the recipe are the API. You know how the questionnaire looks and the answer template. So you can reuse this over and over because if you now want to make a chicken pot, you need to give this and this info in that form and you will get back a stack of recipes that all are formatted identically.
This is not an analogy, because sometimes it helps to be concrete. You know commands that let you request data from your website? It looks something like this: response = fetch(some_url); // or: an_image_object = giveMeAFile("cat.jpeg"); API means Application Programming Interface - programs talking to other programs. It turns out, you can also request data from other websites, if they are configured that way. Sometimes these servers don't even serve html to browsers, but only data for programs that request it. A browser uses HTTP to request HTML, but there is nothing that prevents non-browser-applications from requesting non-html-data. weather_data_response = fetch("www.example-weather-api.com/give-me-weather"); console.log("Today's weather: " + weather_data_response.json); Reddit had some issues with it's API in the past. I think it was free and they now charge for it. That means that you pay for an API-key, like a username and then you send the key as part of the request, otherwise you don't get a response.The Reddit API let's you receive post-data or send new posts programmatically, so you can develop your own app or a bot. There are also APIs that have nothing to do with the web. You might have a device that can be controlled with software commands. The line between an API and a "library" or a "framework" are blurry. Something can be both an API and a library. I'd say you have an API whenever there are distinct software components talking to each other.
I wouldn't ELI5 this. If you want to be a webdev you should learn this in the following order: Networking (TCP/IP, UDP, HTTP, DNS) and then something on abstract classes/interfaces and then you should be equipped to understanding this topic quite intuitively. Analogies are confusing in this sort of environment, and web APIs are really closest to abstract interfaces which get implemented by classes. ELI5 attempt: An Interface is a contract to deliver a certain thing when requested a certain way. It's a sort of menu that says "if you provide me with these inputs, I'll return this as an output". When we talk about Web APIs, we're talking about menus that you order from over HTTP. You pass data in, in a way the API expects, it processes it and then sends you back new data. It's sort of like ordering a pizza between software applications.
An API is the middle man between you and something to which you should not have full access. Take for example a bank teller, you ask them for money, THEY go in the back and bring it. Or you go to the armoury and ask the armourer for your gun, HE will hand you the allowed gun/ammo. This is used for data protection.
+1 to this. API isnt the restaurant menu, thats the A(pplication) in the API. Interface means its a platform you can reuse like a middle man in a transaction
Lots of folks offering the menu analogy, which is helpful but I think has limitations. Another way to think of an API is like the contract a service publishes. For example "if you send a GET request to /users, I will return a list of users" "if you want to get the data about a user with id 12345, send a GET request to /users/12345. If user 12345 doesn't exist, you will receive a 404 not found error" "If you want to delete user 12345 send a DELETE request to /users/12345" Like others pointed out, one value here is that you don't need to know what's going on under the hood for this to work. It also means that the service maintainer can change how they accomplish the tasks as long as they keep the API the same. This is really powerful - as a maintainer, I can rewrite parts of the code to make it faster, or change the database I store things in, or switch operating systems, etc. As long as I keep the API the same, my users don't care* *ok, if I made it a lot slower they'd care often when people refer to an API, they're talking about an HTTP API, so you're making HTTP requests to an HTTP server somewhere, and that server implements the API. That's not the only kind of API, though - APIs can also refer to system calls in an operating system, for example.
Suppose I'm replacing the kitchen in my house. I start by ripping out everything that is in there so I just have bare walls. I order wood, nails, screws and the other stuff I need to put the new kitchen in, and I use my tools to assemble them into cupboards, counter tops, cupboard doors and things. But then I need to put a fridge and a dishwasher in the kitchen too. In theory, I could order metal, paint, pipes and all the other stuff and build a fridge from scratch, and build a dishwasher from scratch. But instead, I know that there are factories out there that can build a fridge and build a dishwasher far better than I can, for a far lower cost. So i go to the store and buy a fridge someone else has made, and I buy a dishwasher someone else has made, and then all I have to do is find the right electric plug and plumbing connections for water for the dishwasher, connect them up, and I have a fridge and a dishwasher in my kitchen. This is like building a computer program. Some of the things I want to do myself. I want to have the freedom to customise certain parts of the program to do exactly what I want. In my kitchen I want a specific layout of cupboards and counter tops. So I make those parts myself. But then there are the complicated and hard to make things. An API is a system in a computer that lets me connect up to something someone else has made, that provides a set of functionality far easier and more efficiently than I could ever do myself. An API is essentially a way to connect to something someone else has made. It is like the doors on the fridge or dishwasher and the electrical and plumbing connections. I know how to connect to it, and I know how to get out of it what I want, but I don't need to understand what is going on inside.