Still if I do choose to make my own custom tailored http client I will most likely use XMLHttpRequest as a way of making the request. Often I just go with it for examples where I just need to make a request for an example when working out a simple client system for an examples that has to do with a back end framework, or something to that effect as to not complicated the process any father than it needs to. In this post then I will be going over some very basic use case examples of the XMLHttpRequest method, as well as any additional topics that might come up when using the method.
The basic process will switch up a little here and there though depending on the kind of request that I would like to make. Often I might need to set some additional headers for the server that I will be sending the request to, and so forth. I will not be covering all the bases with the various kinds of requests here, but I should at least cover some basic examples of get requests at least to start off with.
First off I have a simple example that will be used to just get plain text, and inject that text into a simple text area element. When it comes to just getting some text there is nothing special that needs to be done in terms of response types, and parsing the result, typically at least anyway when it comes to just a basic hello world style example. So then for this I just create a new instance of a request object, open the request, create a handler, and call send.
When it comes to setting the handler I will often want to use the on ready state method to do so. It is in here that I want to check to make sure that the ready state is 4, and that the status of the request is 200. In more advanced examples I might want to check for a given range when it comes to status codes, and will also want to do something when I have a status code that indicates that something went wrong, but for now lets keep things simple.
To get JSON I just need to make the responseType prop JSON, after that the process is more or less the same as plain text. I do not even have to parse the response when I do it this way now.
So I have covered a few basic examples of working directly with the XMKHttpRequest method, however often I will still want to use some kind of http client library, or make my own from the ground up, that has a lot of typically use case examples precoded and ready to use.For example when it comes to working with XMLHttpRequest directly I have to remember things like setting the response type to blob rather than the default text setting when I want to use it to get an image, and on top of that the response is a blob, not an image element. However when it comes to making my own http client I can create a public method that is a kind of load image method that will make a request with the property settings, and parse and return an image element as the response in an on done callback or resolved promise.
Here is then the state of the http method of my utils lib in the game framework at the time of this writing at least. The main http method will take a single object as an argument, that should contain at least a url to the resurface that I want to get, or that path that I want to post to, with a body of course in that case. I have not extensively tested this yet, but so far it works fine for what I want to use if for in my game framework.
Now for a basic example of this to get started with. In this example I will just be using the http method of the utils lib to get the html of my website and inject it into a text area element. So I just call the utils http method and pass an object that contains a url to the home page of this website, The default method is GET all ready but in some cases I might do that anyway for the sake of making this explicit in the code, after that there is setting an on done callback. In the body of the on done callback method I am setting the result of the request as the value property if a text area element.
There was once a time where the use of a pollyfill for XMLHttpRequest was a must, today more often then not it might not be as big of a deal as this is only something that would apply to really old versions of Internet explorer these days. Of course it really comes down to browser share of your site, for me it does not seem to matter everyone is using late versions of IE, when they are using IE at all to begin with, which is not often.
Still If it is desired to push backward compatibility as far back as possible a pollyfill like this might be used to do so.
This is only really needed if for some reason you want to march backward comparability of your project all the way back to IE 5 which at this time is a browser that is over 15 years old now. Maybe if for some reason you get a lot of traffic from China, or some country where there are still a lot of people using old browsers a Polly fill will be of interest. I am a bit of a nostalgia nerd myself, but even I do not bother with this any more.
However if you site analytics show nothing but IE 7, and older chances are there is not much of a reason to bother with the polly fill anymore, and you can just assume that it is there in window to work with.
In which case you can just use the constructor and move on.
Of course you could do what I just did, and throw together your own solution, but it might be best to just use something that is out there all ready, and see that it conforms to some kind of newer standard for this sort of thing. Because fetch is poised to be the new replacement for XMLHttprequest it might be a good idea to make (or find) some kind of pollyfill that does a good job of bringing fetch to older browsers. for that you might want to check out fetch.js.
The XMLhttprequest method might be the best solution for scripting http if you care about trying to get your code to work on a wide range of browsers, as it is the tired yet way of doing so. For the most part I would not loose sleep over it thought if I where to choose to go with something more modern, at least when it comes to looking at what is going on with browser vender’s and versions with this site at least. Still I often seem to prefer to do things in a way that might very well be a bit dated, but still work okay. I hate to waste to much time getting caught up in all kids of habit holes when it comes to how to go about scripting http, it strokes me as something that is a distraction from things that are of real value. So it makes sense to just go with something that works, and move on when it comes to this sort of thing.