How do I fetch JSON data with jQuery?


jquery-logo jQuery’s ajax method provides a way to make an HTTP request for JSON data and then handle the successful result.

Assuming that you have access to jQuery in your web page, fetching JSON data is very simple. The key to this is the jQuery.ajax method. This method takes an object as its first argument. In this object, you can, at minimum, specify url and success properties. The url property is the web address of the JSON data that you want to fetch. It should start with http:// or https://. If the resource is a relative path, then it could be virtually anything, for example: /data/json/customers. The success property is a method. That is, you assign a function to the success property. This function will receive the fetched JSON data as its first argument. Inside the function, you can process that data.

Try it yourself!

See the Pen jQuery AJAX – Basic Example by Kevin Chisholm (@kevinchisholm) on CodePen.

In the above example, we make a call to $.ajax. We pass an object to this method and that object has two properties. The url property has the web address of the JSON data that we want. Notice that this address ends with: ?sleep=2. This just means that for demonstration purposes, we can force the request to be delayed for two seconds. Go ahead and change that to ?sleep=5. You will see that the request then takes five seconds to complete. If you change it to ?sleep=0, then you will notice that the request completes very quickly. Either way, you can control this request and slow it down in order to see more clearly how things work.

The success property has an anonymous function assigned to it. This function will be executed once the $.ajax requests succeed. The function will take the fetched  data as its first argument. So, inside this function we use the JSONView jQuery plugin to inject the JSON data into the DOM.

Important note: we haven’t specified the HTTP verb that will be used for our request. For example, GET and POST are common HTTP verbs used for sending or receiving JSON data, but PUT and DELETE are fairly common as well. The jQuery.ajax method allows us to specify the HTTP verb that should be used for the request, and we specify this HTTP verb in the object that is passed to the jQuery.ajax method. Note that by default, the jQuery.ajax method will make a GET request, unless we specify a different verb, such as: type=”POST”, for example.

So, in the above example, we specified a success method.
It’s important to note, however, that we did not specify an error method. The reason for this was to make the example code easy to follow. However, it is highly recommended that you always provide an error handler when making any HTTP request. Keep in mind that while you may have full confidence in the requests you are making, HTTP transactions are fragile by nature, and in theory anything can happen. So, whatever you do, don’t overlook this small but important detail.

Gettin’ Down with BaconIpsum


angular2 baconipsum json

Sometimes you need Lorem Ipsum, and sometimes you need it in json format via an API call. If you don’t mind bacon references spattered throughout that latin, then Bacon Ipsum can help.

I’ve already written an article about the need to make an API call before that service is ready. And is a perfect tool for that. But if you just need a lot of text and want to generate it via an API, then Bacon Ipsum is a fun tool that can solve that problem.

The overall concept is a bit silly. I mean, lorem ipsum is kind of silly, and having words like  “bacon”, “flank” and “shankle” sprinkled throughout borders on nonsense. But their API works well and is very easy to use. So, if you are in the middle of a dev project and need some dummy text in JSON format, it’s nifty stuff.

Json API

The landing page allows you to generate some Bacon Ipsum on the fly, but if you want the API calls, then go to There  you’ve got very simple instructions on how to get your Bacon using simple query string parameters. These parameters allows you to control how many words and paragraphs will be returned.

Other Bacon-stuff

If you find this all funny and want more Bacon, they also offer a Chrome extension as well as Android and IOS apps that allow you to… well, I’m sure you can figure out what these do… more Bacon. Although I will note that these apps are pretty outdated, so use at your own risk. There is a jQuery plugin, and three.. count ’em three WordPress plugins for increased Bacon madness. And to top it all off: a baconmockup HTML generator. This might be a bit too much Bacon for me. They had me at the JSON API calls.

MyJson – An awesome tool for mock API calls


MyJson LogoSometimes you need to call an API that is not ready yet

So you are working on your front-end code. You have crafted you JavaScript so that it is clever and optimized. Check. You’ve created your “makeHttpRequest” method, and configured a success callback. Check. But there is one problem: the back-end team has not completed the API call that you have to make. Rats.

Sure, you can just create some static “dummy” data. But that is not the same thing as an HTTP request, and your code will not be asynchronous. Ok, so you could wrap your static data assignment in a setTimeout. Yeah, that’s it…. nah, just not the same thing as making a real HTTP request. Double rats. saves the day on this one.

This site is so dammed cool, I can’t get over it. You simply add some valid JSON into the large text area, and then click the “Save” button. You are then taken to a page that shows you two things: your JSON and a URL that you can use to make an HTTP request for your JSON. In other words, you just created your very own API call that returns the exact JSON that you need. Sorry folks, this one is better than the Beatles.

At first I was wondering: “…wait a minute. How can I make an HTTP request like this when can not possibly have added my silly little test domain to their whitelist for the CORS header?” (yes, I actually talk to myself like this. it’s kind of scary). Well, after about five seconds in the network panel, I see “Access-Control-Allow-Origin: *” . Nice.


I literally cannot even begin to imagine the countless hours this would have saved me in the past. Yeah, sure you can spin up something like this on your own, but good gosh; copy, paste, API! how much easier could this be.

Serious Kudos to whoever is behind this.




JSONP With Only Native JavaScript – Part I


JavaScript LogoMost front-end developers consume JSON at some point. It has become commonplace nowadays to fetch data from a cross-domain site and present that data in your page. JSON is lightweight, easy to consume and one of the best things to come along in a while.

Another one of the best things to come along has been this:


jQuery makes fetching JSON trivial. And there ain’t nothin’ wrong with that. But it’s not a bad idea to have a solid understanding of exactly what is going on under the hood.

The big advantage of JSONP is that it allows data to be retrieved from any URL on the planet with no concern for the kind of cross-domain limitations of AJAX. So this means that we are taking advantage of one of the older features of the JavaScript language: the ability to inject a remote script into our page. In a nutshell, JSONP is accomplished via dynamic script injection. In other words, you create a script tag, set the ‘src’ attribute to be any script you like, and that script calls a function in your page, passing it some data.

Now in the real world, your remote script would likely be produced by an API that supports JSONP. In these cases you have probably seen the URL of JSONP call look something like this:

This is a more sophisticated approach and will be covered in Part II. For now, however, we will keep things very simple. In order to do so, we have to have an agreement between our JSON file and our web page. Our web page has a function expression that makes that function available, and the JSON file knows to call that function.

First, let’s take a look at our JSON file.

Example # 1

Example # 1 is our JSON file. It is really just a JavaScript file. It consists of one function call: jsonpCallback(). The sole argument to this function call is an array of objects. Each object has two properties: ‘name’ and ‘accountNumber’.

We’ll come back to this file shortly. For now, it’s just important to focus on the fact that this is simply a JavaScript file that makes a function call, and passes an array to that function.

Example # 2

In Example # 2, we have the markup for our web page. Now there are two things happening here:

1) The function declaration jsonpCallback() might look familiar to you. This is the function that is called from our JavaScript file ‘data.js’. Notice that this function takes one argument: ‘data’. So it expects to receive some data. Inside the function we assume that the data came through and we inspect it in the console.

2) After the function declaration, we dynamically append a script to the head of the document. Now if you take a close look at the ‘src’ attribute of our script, you’ll see that it is ‘data.js’

Putting the pieces together

Now that we have the details laid out, let’s walk through the sequence of events:

  1. The page loads, and the function declaration for jsonpCallback() is evaluated
  2. jsonpCallback() now exists and can be called
  3. We dynamically append a script tag to the page
  4. The URL for this new script tag is data.js
  5. data.js is loaded and the code inside of it executed
  6. data.js calls the function jsonpCallback(), and passes it the array of data
  7. jsonpCallback() receives the data passed to it and we inspect it in the console

Again, this is an extremely rudimentary example. The focus here was to illustrate the core concepts in play: dynamic script injection and passing data to a function. In Part II, we will look at a more dynamic approach to JSONP.

Here is a link to the working example for this argument:


In this article we learned how to implement JSONP using only native JavaScript. We discussed how the script that we dynamically inject into the page calls a function, passing data into the function that it calls.

Helpful Links for JSONP

Making JSONP Calls from HTML5 Web Workers


HTML5 LogoThe importScripts() function can be used to load any JavaScript file asynchronously from within a Web Worker, making JSONP a snap.

I just put the finishing touches on a photo gallery for a fairly large commercial web site. This template involved two dependencies: mustache.js and a jQuery carousel plugin, as well as three JSONP calls. All of this has to happen before anything can be displayed in the browser. Fun stuff.

I’ve spent plenty of time pressing F5 over and over to see how many milliseconds I could shave off the page load time. Since there is a bit of data crunching that also has to happen once all dependencies and JSONP calls have loaded, I started to think that this project would be a perfect candidate for some Web Worker love (of course with a safety net for older browsers). After some A/B testing, I could see that there was no real savings when implementing Web Workers. This is because the average 3-second load time was mostly due to the multiple asynchronous calls, not the data crunching. Since asynchronous calls are asynchronous, they don’t lock-up the browser, and it is only their latency that “keeps us waiting.”

That said, in the process of setting up my A/B testing, I had fun messing with Web Workers, and picked up a few new tricks, so I thought I’d post an article about making JSONP calls from a Web Worker.

If you’re not too familiar with HTML5 Web Workers, you might want to read these three posts; they offer an overview and a quick dive in to the topic:

Getting Started with HTML5 Web Workers – Part I
Getting Started with HTML5 Web Workers – Part II
Getting Started with HTML5 Web Workers – Part III

Before diving into the Web Worker code, I’ll just mention that the JSONP call we make responds pretty quickly, almost too quickly. As a result, it’s tough to demo our Web Worker, because there is no sense of “wait” (I spent over an hour making a pretty “loading” experience that merely flickers for a nanosecond because the JSONP call returns so quickly : – ). So I’ve implemented a “sleep” feature: we add &sleep=NUMBER to the query string. This way, we can make the JSONP call perform a little slowly, which helps to demonstrate our topic. Here is the PHP code that is added to the top of the JSONP file:

Ok, a little JSONP / Web Worker Action Please!

Example # 1

In Example # 1, we have the code for our Web Worker. First, there is the JSONP callback. In this callback, we fire off a message to the script that started the worker, and pass it the JSON data. Note that we need to use JSON.stringify() to convert that JSON data to a string. This is because we can only pass strings as messages to and from a Web Worker. But if we “stringify” a JSON object, that will do just fine.

Next we have set up an event listener. When the calling script sends a message to this Worker, the code inside of the event listener is executed. We create a random integer which is used to tell the JSON page to “sleep” for a few seconds, imitating a slow response. The other random # is used as a cache buster.

After that, we simply make the JSONP call. The importScripts() is oh-so-lovely and makes it super easy to import any JavaScript file.

Example # 2

In Example # 2, we have a simplified version of the click handler for the “Make JSONP Call” button. It simply sends a message to the Worker, which “starts” it.

Example # 3

In Example # 3, we instantiate the Worker() constructor, and then set up the event listener for that Worker. The code inside of this event listener will be executed when the Worker sends this script a message. I won’t drive you nuts by going through it line-by-line, but on a high level, we take the JSON data that the Worker sends us, and use JSON.parse() to turn it back into an object. Then, leveraging Mustache.js, we create an unordered list, using the JSON data that the Worker fetched for us.

Here is a link to the full working example for this article. Make sure you click the “Make JSONP Call” button:


Again, the very act of making an asynchronous script call is not so strenuous for the browser. But I can imagine a case in which you need to fetch some JSON and then crunch the return data before passing it to the calling script. In such a case, the “crunching” is what could bog down the browser. And since data you pass to a Web Worker is essentially “copied,” your script could wind up using more memory than necessary, by getting the JSON data, passing a copy of it to the Web Worker, and then getting a copy back from the Worker once it has finished doing some work on the data. That is three copies of the same chunk of data!

By initiating your JSONP call from the Web Worker, you get the data, crunch the data, and then pass the data to the calling script. This removes one “copy” from the whole scenario. And, I’m thinking that after sending the data from the Worker to the calling script, you could probably delete the data inside of the Worker, freeing-memory. Although it will probably get cleaned up by garbage collection. More fun stuff to investigate.

Happy Web Worker-ing!


Helpful Links for Web Workers

Complex Multiple Script Loading Using the jQuery.when() Method and the jQuery.Deferred Object — Part II


jQuery LogoWhat happens when your JavaScript code depends on not only multiple asynchronous scripts, but also one or more JSONP calls? Once again, jQuery.Deferred() and jQuery.when() save the day.

In Part I of this article: “Complex Multiple Script Loading Using the jQuery.when() Method and the jQuery.Deferred Object Part I“, we discussed the complex nature of multiple asynchronous dependencies. In that article, we were able to count on jQuery.when() to pay attention to the resolution of our jQuery.Deferred objects. In this second part, we’ll complicate things even further by adding a JSONP dependency. The “complication” is the fact that the success of the JSONP call requires us to re-think how we will leverage our jQuery.Deferred object’s resolution.

In my opinion, the asynchronous script calls are fairly easy to manage:

But what about a JSONP call? How do we squeeze that scenario into the jQuery.Deferred / jQuery.when() paradigm?

The approach I have taken starts with a variable that is set to an unresolved jQuery.Deferred object. As soon as you create this variable, you can then program around it. In the true spirit of JSONP, you can name your callback whatever you want. If the server supports JSONP, then you can assume that it will call your callback, passing in the much-desired return data.

Here is a pseudo-code walk-through:

Example # 1

In Example # 1, we have the core code that makes this all work. The interesting thing is that the actual JSONP call comes last. What we do beforehand is set up the tools we need to handle this asynchronous event. What makes this scenario a bit special is that you manually resolve the jQuery.Deferred object in the JSONP callback: “foo.resolve()”. This very nicely kicks in the .when() method that is chained to the return value of the jQuery.when() call.

Example # 2

In Example # 2, we have the code for the full working example. It builds upon the full working example from Part I of this article, but the added functionality has no connection to the form validation. The point that is (hopefully) being made here is:

  • This code provides a way to ensure that multiple asynchronously loaded dependencies are loaded before further action is taken.
  • This code checks to see if any of the asynchronously loaded dependencies have already been loaded in the page (possibly by hard-coded synchronous calls or another script).
  • This code allows for the inclusion of an asynchronously loaded JSONP dependency.

Going through the code line-by-line would be repetitive as that was already done in Part I. What might be helpful is to look at the code and see where the approach taken in Example # 1 has been worked into the full working code (Example # 2).

Here is the URL for the full working example:


In this article we learned how to accommodate a JSONP call as an asynchronous dependency. We leveraged the jQuery.Deferred object and the jQuery.when() method to manage and act upon the resolution of the JSONP call.

Problems Making JSONP Calls in JSFiddle – PROBLEM SOLVED


JS Fiddle LogoAll the JavaScript you write in the JSFiddle “JavaScript” box gets wrapped in an anonymous function and assigned to the window.onload event of an iframe that is shown when you click the “Run” button.

Last week I published this post: Problems Making JSONP Calls in JSFiddle 

As I was testing out some code, I noticed that JSONP calls were failing when using I took a look at it and just found the answer. It wasn’t too big a deal, just needed to understand how JsFiddle executes the JavaScript code that you put in the lower-left-hand box (i.e. the “JavaScript” box).

Here is the code I testing, that was failing:

In this code, I use the “var” keyword to declare “myCallback” as a function expression, just like I was told in JavaScript summer camp back in the 70s. But even when using the “var” keyword, any variable declared in the global scope becomes a property of the window object. Anyhooo, I confidently assumed that my variable “myCallback” (or window.myCallback) would be available to the script that is loaded by the JSONP call. But that code failed and the following message appeared in the console: “myCallback is not defined”. Bummer.

Well, after a few minutes poking around in Google Chrome Web Inspector, I found the issue:

As I had suspected, JsFiddle executes your JavaScript code in an iframe. What I did not realize at first, is that it wraps all of that code in an anonymous function, that is assigned to the window.onload event. So by using the “var” keyword, my “myCallback” variable became private to the anonymous function. Here is the code that is actually executed by JsFiddle when I clicked “run”:

As a result, my “myCallback” variable (i.e. the function expression) is private, and not available to the outside world.

The answer was simple. I just had to force my “myCallback” variable to be global by removing the “var” keyword:


This forces “myCallback” to be an implied global, which in-fact becomes a property of the window object. It’s the exact same thing as if I had written: “window.myCallback – function()….”

Here is the link for the code that fails:

Here is the link for the fixed code:

Same thing, only let’s avoid implied globals, and explicitly attach “myCallback” to the window object:

Again, no big deal. But if you found yourself pulling your hair out and were googling for an answer, hopefully I saved you a few strands of hair.

: – )





Problems Making JSONP Calls in JSFiddle


JSFiddle Logo
If you are pulling your hair out while trying to demo a JSONP call with JSFiddle, don’t bother. It won’t work out of the box.

There is no doubt that JSFiddle is a super-useful tool for saving little demos that you can share with others.  I use it like crazy when providing simple demos in this blog. Tons of cool features and in general, a brilliant idea.

One little quirk I ran into this morning is JSONP calls. I’m writing Part II of a post called: “Complex Multiple Script Loading Using the jQuery.when() Method and the jQuery.Deferred Object”. In this second part, I introduce the tricky scenario of adding a JSONP call as a dependency, which is in addition to other dependencies that are multiple asynchronous  JavaScript calls that may (or may not) have already loaded in the page (I know, I know….. I need to get a life).


When attempting the code in example # 1, I got the following error: “myCallback is not defined”.

Example # 1

My guess is that JSFiddle uses iframes to render your test code. I’ve not made any attempt to look into this further, and I’m sure the answer is likely a call to “parent” or something similar. But just in you are pulling your hair out trying to demo a JSONP call using JSFiddle, hopefully this will save you the 20 minutes of troubleshooting that I just did. It won’t work out of the box (again, probably due to the use of iFrames). When I figure out the answer, I will post it. I’ll try to look into it this weekend.


Mustache.js – The Absolute Basics


Mustache.js LogoIf you’ve been writing client side code for more than 15 minutes, you have likely had to consume and present JSON data. This is becoming a common scenario for front-end web developers.

The problem is that in most cases, you are inserting the return values into the same markup. So this means that you might be writing your own for-loops and element creation functions. But even with the help of the mighty jQuery, this can get tedious. More importantly, you are likely writing the same code more than once, each time customizing it for the specific situation. Well, regardless of the details, if this even partially describes some of the challenges you have faced lately, then it is likely that a client-side templating solution is needed.

Enter Mustache.js

Mustache.js is a lightweight JavaScript library that provides client-side templating. The feature-set is intentionally small. While some may see this as a drawback, I agree with their approach. The footprint is so small, that it is really a non-issue when it comes to considering the additional HTTP request (and you can, of course, concatenate it to your main JS file if you so choose). Websites such as Twitter, CNN and eBay, Inc. have turned to this JavaScript library, which is a testament to its power and usefulness.

The syntax is pretty simple

TEMPLATE = Your HTML code with {{VALUE}} placeholders
DATA = Your JSON Data

Example # 1

Here is the fully-working link for Example # 1:

In Example # 1, we call the render() method, which is a static member of the Mustache object. This method takes two arguments: the templated markup and the JSON data. This is not the most efficient way to utilize the method, but it is a good way to demonstrate how simple it is. Just create your HTML wtih the {{tag}} syntax where you want your output, and provide some data. Then use jQuery to append the return value of this method call to the element with the id of “container”.

Example # 2

Here is the fully-working link for Example # 2:

Mustache.js spares you the headaches of writing the same JSON iteration / DOM creation code over and over with each project.

In Example # 2, we use a slightly more advanced approach. First, note the SCRIPT tag with the id of “template”. Instead of giving the type attribute a value of “text/javascript”, we use type=”text/html”. Since this makes no sense to the browser, the text node inside of the SCRIPT tags is ignored. But at the same time, that same text is available to us, so it is a great place to store template markup.

Inside of this SCRIPT tag, we have the opening and closing {{#cities}}{{/cities}} placeholders. This is used as a loop. What it does is tell Mustache.js: “Hey for each one of the elements in the ‘cities’ array, populate the markup accordingly.” So, Mustache.js iterates over that same markup for each element in the “cities” array, and inserts the value of cities[“name”] where the {{name}} placeholder appears.


These example are very basic and there is much more to dive into with Mustache.js. My hope is that this post has provided an overview that, at minimum, helps you to begin understanding and implementing this library.

Helpful Links for Mustache.js