A Quick Glance at the Fetch API
Let’s look at what a simple fetch looks like:
What is happening here?
How do we check for a successful response?
Since the fetch promise would only reject a request if it was unable to complete it, we need to manually validate if a response is good and throw an error if it is not.
A generic response from a server looks something similar to this, when logged on the console:
With that in mind, to evaluate the status of a response you can use its properties: “response.ok”- checks for a status in the 200s and returns a boolean “response.status”- returns an integer with the response status code. Default is 200 “response.statusText”- returns a string who’s default is “OK” or a relevant error message
Now we can update the example from above to validate the response
Now what’s happening?
1) We are still passing the URI (‘examples/example.json’) as an argument.
2) The fetch returns a promise that eventually becomes the response.
3) The response is then passed to .then to be used in the way you specify.
4) We have an if-statement that basically says if response.ok is not true, throw an error with the response.statusText, which will then trigger the .catch.
Why do we need this?
To prevent bad responses from going down the chain and breaking your code later on.
We need to throw this error manually, because as explained above, error messages received within a response from the server do not register automatically as an error and do not show up in the catch method.
The result will be that nothing will be delivered by the fetch and yet the client will be clueless that something has gotten wrong.
Now we need to “read” the response in order to access the body of the response.
Luckily, there’s a method for that: “response.json();” which we apply to the response.
Next we update our code to include it.
Now what is going on?
Simple. Think of it in separate steps.
1) Fetch the resource at the given path. (Fetch gets the path to the resource and returns a promise that will resolve to a response object.)
2) Then validate the response. (This checks to see if the response is valid (200s). If not, skip to step 5.)
3) Read the response as JSON
4) Log the result (The result being the JSON data received from the body of the response.)
5) Catch any errors
Now that you have seen the basics, we can compose more advanced fetches.
The default request method is a "GET" method; which is what we have seen so far. The most used methods and what they represent are:
GET: Read/Retrieve POST: Create PUT: Edit/Update DELETE: You guessed it, this simply means Delete.
Here's an example of a post method that is creating a new user:
Note that this example fetch is posting (sending to the server) data in plain text format. In modern front end development this is less common. The most common content type for our methods will be the application/json format, as seen in the following example:
Did you notice something new above?
The Body of the fetch is where we place the data that we want to send to the server for permanent storage, with our POST or PUT requests. Because we can only send plain text over http, we have to convert our data from its original JS format to a string. We do that with the JSON.stringify() method.
Requests with GET or DELETE method do not require a body, since normally they are not expected to send any data, however you can include a body in those requests as well, if needed.
HTTP headers allow us to perform additional actions on the request and response. You can set request headers by using as you see above.
Headers can be sent in a request and recieved in a response.
Therefore you can use the headers of the response you receive from the server, to check the content type of its body, and make sure you are recieving the right format before going any further in the process. An example of this would be:
Note that a Header method will throw a TypeError if the name used is not a valid HTTP header name. A list of valid headers can be found here
All rights reserved, 4Geeks LLC 2021. Read more about 4Geeks and what we are going here.