In any case the fetch method is still without question a feature in modern browsers that is worth a moment of my time to write at least one post on the subject. I have done so all ready with XMLHttpRequest, and axios after all.
In this section I will be going over just one example of the fetch api when it comes to just making a simple get request. When it comes to the various other kinds of requests such as post requests one will need some kind of back end system to post to, so that will be something that I will be getting to in later sections of this post.
For starters I think an example that is just a basic get request would be in order, as that is often the case with these kinds of posts. Say that I want to preform a get request to just get the html text of a given page at a certain location on the open web, for argument sake how about just the text of this very blog post? In that case fetch just needs to be given one argument which is the URL of the resource that I want to fetch. This is a whole world more simple compared to using XMLHttpRequest that often proves to be a bit of a pain by comparison.
So when calling fetch and giving the URL of this page as the first argument what is returned is a promise. I will not be getting into detail about promises here, but the typical basic use of them involves attaching then and catch calls that will fire depending on the outcome of the request.
If all goes well in the body of the next then call I will have access to a response object. This response object will not have the text of the page at the ready necessary, but there is a method of the response object to get just that tough. In this case I am not getting JSON, but html that can be thought of as just plain text content, so calling the text method of the response API will give me what I would want from the response object in this case. In the event that there is some kind of error the catch call will fire, and in the body of that method I can potentially handle the error.
The fetch method just like XMLHttpRequest can of course be used to preform other types of requests other than get requests. There are a few of them to mention, but in general there are GET requests, and POST requests. A Get requests for the most part is to just get a resource at a given URL, while a POST requests is to upstream a body of content to a back end system.
In any case to preform a POST request I can do more or less the same thing as with a GET request, only I need to provide an options object with at least a few properties. In this options object I am going to want to set the method of the requests to POST, and I am also going to want to given a body that is to be uploaded to the server. Often when it comes to these kind of requests it is called for to provide at least a few headers also, such as Content-Type in this case I will be sending json to my sever script. Speaking of a sever script yes I will of course need some kind of back end system to post to. SO in this section I will be going over a simple project example that will contain a sever script that will respond to both get and post requests as well as some html that will preform a post request to this sever script.
In my project folder for this example I have a public folder and in this public folder I just have a single html file. This html file has a text area that will sever as a place to inject some text that is a response from the sever script. Inside the body of a script tag I get a reference to this text area element, and preform a post request using the fetch api.
Now for the sever side script for this example that will respond to both get requests as well as post requests. I have everything here in a single file, and there is actually a lot to cover with it when it comes to the many nodejs request that I am making use of beyond just that of the http module. For example I am using the promisify method of the nodejs built in util module to create file system methods that will return a promise using methods from the file system module. When it comes to the code that I am using to respond to get requests, including get requests for the index html file that will sever as my client system for this example I based all of that off of the state of the source code for another project that aims to be just a very basic static web site sever example.
I could go on and on about all the various details about this script, but the main part that is of interest for this example at least is the code that has to do with responding to post requests. The METHODS.POST method is then the method of interest with posts requests then, and it is in this function that I am parsing the incoming body from the client system, parsing the string as JSON, and using values in the body to create and respond with a request.
If you are concerned about support for older browsers, then a polyfill for fetch will have to be used, or just do things the old fashion way with XMLHttpRequst as any polyfill will likely use just that. A popular polyfill for fetch can be found on github here at github.
Another option would be to just not use fetch at all and chose or make an http client, which is what I would often do rather than using fetch when it comes to working on an actual project where I will need to script http requests.
In addition I would not say that fetch is a replacement for various user space http clients that wrap XMlhttprequest rather then that of fetch. If a client is designed right there is a potential to get a best of both world situation between browser support and supporting later features like promises.