 What is the Fetch API? It's a modern replacement for XML HTTP request that lays the foundation for progressive web apps. It includes much of the code you had to write for yourself, handling redirection and error codes, and decoding the result. Like most new APIs, Fetch is built on promises. This is a much cleaner interface than using event listeners, and it simplifies error handling. Fetch can be used with or without service workers. While the service worker APIs use Fetch heavily, you can also use it for your own tasks. Finally, Fetch supports cross-origin resource sharing or cores. We'll go into the details in a few minutes. Let's look at a simple example. Here, we're fetching a JSON file named example.json, decoding it, and using the data. Fetch returns a promise, so we use then to wait for a result. Once we have it, result includes a function for decoding the JSON. That also returns a promise, so we use then to wait for the decoder to finish. The final catch intercepts any errors that come up. This is one of the things that makes Fetch so nice. Your error handling is all in one place. Let's talk a little more about handling errors. By default, Fetch doesn't throw an exception if the server returns an error, but instead returns a normal response. The response.ok property will be true if the server returned 200 and false otherwise. You can always check response.status for the actual code. In this example, we're throwing an exception if the file can't be found. This is the best practice, and you should make a habit of checking response.ok early. Now, I promise to talk about cross-origin resource sharing. Let's start by looking at a problem it solves. Assume your page is running from food.com, and you try to get something from example.com. What's going to happen? The browser has strict rules about going outside your domain to fetch resources, so you'll likely get an error. It's not Fetch's fault. The same thing can happen with XML HTTP request. Most developers resort to hacks to get around this using JSONP or dynamic HTML to load content. But there's a better standardized way called cores. Cores, which is short for cross-origin resource sharing, enables Fetch to retrieve resources from outside of your application's origin. So what's an origin? It's a combination of scheme, host, and port. HTTP www.example.com has a scheme of HTTP, port 80, and the host is www.example.com. If any of these things change, say from HTTP to HTTPS, that's a different origin. The browser is in charge of enforcing the same origin rule, and it provides a few loopholes. Generally, you can load scripts, images, and other media files from a different origin. But if you try to load some XML or JSON from another origin, you'll get an error unless the other origin gives permission. Here's the cores implementation in a nutshell. When the browser makes a cross-origin request, it adds a special origin header to the request. If the accepting server allows the request, it will add an access control allow origin header to the response. The browser will note the response and allow cross-origin access to this location. If you have a server-side application, it's easy to add access control allow origin to your responses and get rid of hacks like JSONP. If the server doesn't support cores, fetch will return an opaque response. The content is in there, but any attempt to read it cross-origin will throw an exception. Note that fetch uses cores by default. In this example, we're forcing it to disable cores just for demonstration purposes. Why do this? Imagine you have an iframe with the same origin as the response. You could pass the response object to it, and it can use the result. This becomes important when you add offline support to an app and need to cache responses from different origins. We've been using get, but you can use any HTTP verb. Here we're using the head method to get the size of a resource without actually loading the resource itself. The content length field contains the size and bytes. What if you want to send some data? You can use the post method to send it. This is an HTTP request with a body, so you need to supply that as body property. Remember that you are responsible for encoding the body properly, and you should always encrypt any sensitive user data. We can post a form easily using a form data object. Just create a form data object, passing it a DOM node, and the data is ready to use. This is much easier than individually compiling key value pairs. You can also set custom headers for fetch requests, and you can set headers for responses. Note that sending custom headers with cross origin requests will cause your request to be preflighted. This means an options message will be sent to the other server first, and the browser will check for access control allow origin on return. Also, not all headers are modifiable. Some are guarded, such as origin, and writing will fail silently or with an error depending on the header. One last trick for using headers. If you don't always know what type to expect for a request, you can look at the content type header. Think of user-generated content or a server that's in the process of migrating from JSONP to straight JSON. Here's one quick example to review the fetch API. This example gets an image, extracts the data, and appends it to the DOM. Read responses blob and make image node are functions that we wrote. The read responses blob function extracts the data from the response, but first it throws an exception if the input response is not in the 200 range. We pass that data to make image node. This takes the image data and packages it as an image node to be added to the DOM. Here, we're using create object URL to generate a data URL with the image and setting it as the source attribute in an image tag. The old way to do this was to pass a files URL to the source attribute and then capture the load and error events on the image tag. The fetch-based version is much cleaner and simpler. Now it's your turn. Go to the fetch API lab. In there, you will practice making HTTP calls, working with responses, using custom headers, and using cores. Good luck. One last thing. If you're an instructor, this final slide links to more information on fetch. If you're a student, these links can be found in your textbook. You may want to use these while you are working on the lab.