What is an API? An application programming interface is a URL that you can make requests to get information back from. It's like website but only for machines. It's a method that one computer can request information from another.
Note that API is also used to describe how something is used. If I wrote a fox object in JavaScript and gave it two methods:
eat()andspeak(), you could call those two methods its "API". A similar but slightly different meaning for the word. I just point that out because it can be confusing. For the rest of this course, we're talking about endpoints that we can call to get data from.
Now that we speak the language of APIs, let's dive into making some server requests. Let's walk through the hypothetical process.
Let's say you're making a weather page where the user enters their zip code and gets back their forecast for the day.
- The user navigates to your page and the page loads.
- The user types
98109into the search bar and hits enter - Your app makes a request to
api.example.com/weather?zip=98109 - The API response
{ "temperature": 75, units: "F" } - Your app decodes the string to an object using
JSON.parse - Your app updates the page to say "The current weather is 75ºF"
So let's dive into a few things:
- Who is makes the API? It depends. It could be you; your frontend could be requesting against a server you yourself wrote (a topic for a different class.) Or it could be against a myriad of public and free APIs. Or it could be a service you pay for.
- Check out these publically available APIs.
- Whats is the
?zip=98109part of the request. This is called a query string. It allows us to send parameters to a request (like sending parameters to a function) that it can use. In that case, we're sending the zip code we want the weather for. If you want multiple queries, they are separated by an&e.g.example.com/weather?zip=98109&day=tomorrow. - What variables you send via querystring will be determined by the API.
Okay, so let's make our first request to a public fox API. I'm going to be attaching this to a button so we don't hammer our poor friend's APIs. Running these APIs isn't free.
I don't take responsibility for what images this gives back. They should all just be cute foxes.
<button id="fox-btn">Gimme Foxy</button>
<div id="fox-target"></div>
const FOX_URL = "https://randomfox.ca/floof/";
const foxes = document.getElementById("fox-target");
function addNewFox() {
const promise = fetch(FOX_URL);
promise
.then(function (response) {
const processingPromise = response.text();
return processingPromise;
})
.then(function (processedResponse) {
const foxObject = JSON.parse(processedResponse);
const img = document.createElement("img");
img.src = foxObject.image;
img.alt = "Cute fox";
foxes.appendChild(img);
});
}
document.getElementById("fox-btn").addEventListener("click", addNewFox);
Let's dissect this.
Requests take time. The process of calling out to the Internet, reaching the server, the server processing, responding, and coming back takes time. It could be very fast. It could be a minute. You don't know until it happens. You need to have the ability to wait in your code. This is called async code, the A in AJAX.
JavaScript has several ways of dealing with this. We're using a way called promises. A promise represents a future value. With a promise, you can give it a function with its then function to run whenever it gets its answer back. In this case, we say "hey, you're going to get some text back from this API, so we need that text.
fetch is a function (builtin for the browser) that allows you to give it a URL like https://randomfox.ca/floof/ and it will try to get information from that API. In this case we're asking for a random image of a fox.
fetch gives you back a promise. Then we need to tell it what we think the API is going to send us back. In our case we're saying it's going to be text() from the API. There are others (and I'll show you one in a sec.)
You can do what's called promise chaining. This allows you to do one async action after another. In our case, we don't know how long it will take to transform our response into text (it's basically instant and usually is but it could not be). In any case, by returning the promise at the end of the first then, we then can use its data in the second then. That's why that's weird that way.
In the second then we read the image property which has the URL, we create an img tag, and append it to the DOM. The result is we get a cool fox pic!
Okay, let's tweak it minorly.
<button id="fox-btn">Gimme Foxy</button>
<div id="fox-target"></div>
const FOX_URL = "https://randomfox.ca/floof/";
const foxes = document.getElementById("fox-target2");
function addNewFox() {
const promise = fetch(FOX_URL);
promise
.then(function (response) {
const processingPromise = response.json(); // json instead of text
return processingPromise;
})
.then(function (processedResponse) {
// we get to skip this line since it'll already be an object
// const foxObject = JSON.parse(processedResponse);
const img = document.createElement("img");
img.src = processedResponse.image;
img.alt = "Cute fox";
foxes.appendChild(img);
});
}
document.getElementById("fox-btn2").addEventListener("click", addNewFox);
A slight difference, but if we know we're going to get JSON back from the API, fetch can do the parsing directly for you with the json() function.
Practice exercise
Try this on your own:
- Create a button and a paragraph.
- Use
fetchto request a simple JSON API (https://jsonplaceholder.typicode.com/todos/1). - Parse the response and display one piece of data in the paragraph.