Well, of course Javascript has it built in, or how could any Javascript library offer a convenience method for it? The difference being that the convenience methods offer, well, convenience, and a clearer, simpler syntax.
– PistosJun 26 '14 at 19:53

@AlikElzin-kilaka Actually all the answers above are off the mark (infact the linked W3 docs explains "each component of this name is potentially misleading"). Correct answer? its just badly named stackoverflow.com/questions/12067185/…
– Ashley CoolmanMay 28 '16 at 11:58

1

So If I wanted to change this from a GET to a POST request, I would just have to change "GET" to "POST", and then add the data I want to send in instead of the null right? I wouldn't have to change anything else?
– cjnashMay 23 '18 at 14:15

note that this isn't working in IE 10 when trying to access url in a different domain than the page's domain
– BornToCodeSep 30 '13 at 9:35

5

@BornToCode you should investigate further and possibly open up a bug on the jQuery issue tracker in that case
– ashes999Oct 8 '13 at 16:58

75

I know some people want to write pure Javascript. I get that. I have no problem with people doing that in their projects. My "In jQuery:" should be intpreted as "I know you asked how to do it in Javascript, but let me show you how you would do that with jQuery, that you might have your curiosity piqued by seeing what kind of syntax conciseness and clarity you can enjoy by using this library, which would afford you numerous other advantages and tools as well".
– PistosJun 26 '14 at 19:47

26

Observe also that the original poster later said: "Thanks for all the answers! I went with jQuery based on some things I read on their site.".
– PistosJun 26 '14 at 19:49

Since this answer is one of the top results for googling "http request javascript", it's worth mentioning that running eval on the response data like that is considered bad practice
– KloarMay 19 '14 at 9:47

8

@Kloar good point, but it would be even better to give the reason why it's bad, which I guess is security. Explaining why practices are bad is the best way to make people switch their habits.
– BalmipourSep 16 '15 at 11:16

Browser support is now good in the latest releases (works in Chrome, Firefox, Edge (v14), Safari (v10.1), Opera, Safari iOS (v10.3), Android browser, and Chrome for Android), however IE will likely not get official support. GitHub has a polyfill available which is recommended to support older browsers still largely in use (esp versions of Safari pre March 2017 and mobile browsers from the same period).

I guess whether this is more convenient than jQuery or XMLHttpRequest or not depends on the nature of the project.

I might save someone some time by mentioning that you can do this to include credentials in the request: fetch(url, { credentials:"include" })
– EnselicMar 9 '17 at 11:01

Except it does not allow you to get XML...
– bugmenot123Aug 16 '17 at 12:28

@bugmenot123 window.fetch doesn't come with an XML parser, but you can parse the response yourself if you handle it as text (not json as in the example above). See stackoverflow.com/a/37702056/66349 for an example
– Peter GibsonAug 16 '17 at 22:56

This answer should be the accepted solution in 2019! Thanks for posting this, saved me some time.
– Daniel SchuetteJan 23 at 0:40

IE will cache URLs in order to make loading faster, but if you're, say, polling a server at intervals trying to get new information, IE will cache that URL and will likely return the same data set you've always had.

Regardless of how you end up doing your GET request - vanilla JavaScript, Prototype, jQuery, etc - make sure that you put a mechanism in place to combat caching. In order to combat that, append a unique token to the end of the URL you're going to be hitting. This can be done by:

var sURL = '/your/url.html?' + (new Date()).getTime();

This will append a unique timestamp to the end of the URL and will prevent any caching from happening.

The problem is that Mac OS X doesn't come with Prototype pre-installed. As the widget needs to run in any computer, including Prototype (or jQuery) in each widget is not the best solution.
– kiamlalunoAug 7 '10 at 5:05

The best way is to use AJAX ( you can find a simple tutorial on this page Tizag). The reason is that any other technique you may use requires more code, it is not guaranteed to work cross browser without rework and requires you use more client memory by opening hidden pages inside frames passing urls parsing their data and closing them.
AJAX is the way to go in this situation. That my two years of javascript heavy development speaking.

$http.get('/someUrl').
success(function(data, status, headers, config) {
// this callback will be called asynchronously
// when the response is available
}).
error(function(data, status, headers, config) {
// called asynchronously if an error occurs
// or server returns response with an error status.
});

If you want to use the code for a Dashboard widget, and you don't want to include a JavaScript library in every widget you created, then you can use the object XMLHttpRequest that Safari natively supports.

As reported by Andrew Hedges, a widget doesn't have access to a network, by default; you need to change that setting in the info.plist associated with the widget.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).