 Are you looking for an easy introduction to the Fetch API? If so, you've come to the right place. I'm Sarah Clark, and I'm here to walk you through this new way to access the web. The Fetch API is a modern replacement for XML HTTP request. It includes much of the code you used 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. If you have been watching the series, you've seen this example before. 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, the result object includes a function for decoding JSON. Promises form a pipeline, so we add a function to log the text. 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. Speaking of errors, you may need to write some extra code. Fetch doesn't throw an exception if the server returns an error, but instead returns a response and sets the OK property to false. That could lead to problems down the pipeline. In this example, we're throwing an exception if the file can't be found. This is a best practice, and you should make a habit of checking response.ok early. Using async and await make your code even more readable. These were introduced in ES 2017. You can use ordinary try and catch statements for error handling. In this case, we're setting the JSON result to contain the error if anything goes wrong. Fetch handles all of HTTP verbs with equal ease. You can easily use any verb, request field, or response field. Here, we're using the head method to get the size of a resource without actually loading it. 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 a 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, pass 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, and allow origin on return. Note that some headers are read only. Writing may 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. OK, I want to talk about the response object for a moment. Most of our examples have read it as text, but you can extract several other formats. In addition to text, you can decode JSON object, extract binary data, convert into form fields, and get the raw bytes. Each of these methods works in the same way, returning a promise with the decoded value. Let's look at reading a binary object. In this case, we'll load an image, decode it to a binary object, convert it to an image node, then add it to the DOM. Note that readResponse's blob and makeImageNode are functions that we write. This is the first thing we call after fetch. As usual, it throws an exception if the request failed. Then it calls response.blob. A blob is the generic name for a binary large object. We're using it here to load the entire image into memory. How do we convert that into an image we can use? Since URLs can encode data, we'll ask the URL class to encode the image in a data URL. Then we can create an image node and attach the data. The old way to do this was to pass a file's URL to the source attribute and then listen for the load and error events on the image tag. The fetch-based version is much cleaner and simpler. Now we have a node, but it's not yet visible. We'll find a placeholder span and append the image inside it. I need to tell you about one last thing, and that's cores, cross-origin resource sharing. It's a key part of the browser's security model. 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, and 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 your application's origin. So what's an origin? It's a combination of scheme, host, and port. HTTP colon slash slash 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, it'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 could use the result. This becomes important when you add offline support to an app and need to cache responses from different origins. 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. When you're done, come on back to become a Promises Ninja, and I'll see you then.