Hello, and welcome to our lecture on AJAX and JSON. So we are going to change a little bit of how we have been working with our request-response cycle. This is my happy little diagram of how these applications work, right? So you're sitting here in a browser, and there's this thing called the document object model. And I like to think of the document object model is it a data structure that represents, in a sense, the pixels that you're seeing on your screen, like you're seeing me on the screen right now. It's that last little layer of the pixels. And the document object model is the data structure that the browser maintains to keep track of what it's going to draw. So if you scroll up and down, it knows what's below your window, etc. And when we're interacting, like clicking on things, we click on something in the document object model, and the browser goes, I know what to do with that. I'm going to make a connection on port 80, send a get request or whatever. And there is like, your application's running in the server, it reads urls.py, picks one of the views, loads code up, maybe loads a form up. Gets some templates, loads some data from a model or maybe stars at a model, and then sends, HTML plus JavaScript back. And the browser sees that from the server, it constructs the DOM. And then, as we've seen, it sort of starts JavaScript. And that JavaScript afterwards, after, in a sense, there is no more connection, the JavaScript can talk to the browser. We've had it add things, delay things, change the color, show a spinner. We've done all that stuff, right? But now we're going to do something different. At the point where it is no longer connected, we are interacting with the DOM and doing things ourselves. We're clicking, and scrolling, and doing who knows what, right? But now that is going to be seen and intercepted by the JavaScript, and the JavaScript is going to make a request-response cycle. It's still going to pick a view, going to grab maybe a template, some data, not so much form, sorry, model, and then send data back. And then AJAX is going to parse that data and update something on the DOM, and then you're going to see it. And it really allows a little chunk of the screen to be updated without having to update the whole screen. When we're doing a full request-response cycle, like when we submit a form or click an anchor tag, that changes the whole page. Even though we've done things like putting navigation across the top to make it look like it's not changing, now we are going to leave most of the page intact and change a little tiny bit of that page. And this is called AJAX, for a strange, strange historical accident or whatever. So what we're talking about is data on the web. So the web was created in 1990, became popular in 95. And JavaScript came out in like 1995. And so almost ten years later, we're looking at this JavaScript and realizing, if we just add one little thing to the browser and let the JavaScript make its own request-response cycles, then we could do a lot with that. And so we're like, this is a really cool protocol, it made all the server infrastructure send HTML back. Why don't we make it so it sends something else back? And so the idea was is the data would go back and forth between JavaScript, JavaScript already could talk to the document object model. 2003 is just a little bit before jQuery was built. But by the time jQuery was built, this whole AJAX data on the thing was going pretty well. So the thing everyone thought of in the early times was the notion that we would send XML back and forth. And XML looks kind of like HTML, it has angle brackets. And XML was being used as a data representation format. In many kinds of situations, it's still being used as data representation format. But it turned out it wasn't as easy to use as a data interchange format. So there's difference between two pieces of software sending data back and forth to each other and storing something on disk for a long time and then reading it like a Word document back and forth. So XML, which was really good for documents, we originally thought it was going to be good for sending data back and forth. And that is why it's called AJAX, because the X stood for XML, even though these days we hardly ever send XML. And in this class, I'm not going to bother sending XML, even though I could do it to prove the point. AJAX now is more of a generic, it doesn't really mean XML. And so once we decided that we were going to move data, we had to figure out a wire format. And so what would go back and forth across the wire? And the idea is whether you're running a JavaScript, or Java, or PHP, or Python, each of those has their own syntax for variables, their own syntax and their own methods, etc. And so those weren't seen as sufficient to move data back and forth. And that's why for a while we used XML as our wire format. So they would convert to XML and then convert from XML. But after a while, JavaScript turned out to be a much better solution as the wire protocol. And so JSON is a wire format, and at this point, it's pretty much the most popular wire format. And so it looks like JavaScript constants, with curly braces, key-value pairs, and it also looks like Python, dictionaries and lists. Which is really in the time in 2005, 2004, I thought it wasn't all that popular back then. And the fact that it looks like Python is like a historical accident, where Python became popular much later, 2008, 2009, 2010, maybe. Certainly now, 2012-13, Python's like crazy cool. But back in 2002, 2003, Python was still kind of like a shadowy language. Now, a wire format is a definition of what's supposed to run across the wire. So no matter what programming language, whether it's Python or JavaScript, you need to send it the right way. So inside a Python, you have a dictionary, then you have to prepare to send it across the Internet. And you have to do what's called serialize, which converts it from the internal format to the agreed upon external format. And then it's transported, and then the destination end grabs it, de-serializes it, decodes it, and then puts it into whatever form. In this case, it started out as a dictionary and it came back as an object. And so that's the idea, that JSON is while it's moving. And serialization is encoding it for movement and de-serialization is decoding it for movement. So the notion of JSON, I mean, now is a pretty well understood concept, but certainly in 2002, 2003, 2004 is like XML is better. And so there was this moment where the world powers, the smart architects, all thought that XML was the answer. because it was an answer to some problems, it just wasn't the best answer for this. But when they built it first time, they decided that they would send it as XML. And Douglas Crockford and others were looking for a simpler, lighter way to send data back and forth. And they settled on the object literal notation, which is key-value pairs and an array. And so it's a pretty nice extensible with nesting, an extensible format. Douglas Crockford is sort of the one who popularized this, but claims he's, rightfully says, he didn't invent it, he just looked at it and said, I like it, I'ma start using it. And it had the advantage that JavaScript understood it. So half of your, the de-serialization part on the JavaScript side was pretty easy. And we didn't want to write a lot of JavaScript code back in the day. So the server's could figure out how to write this JSON, send it, serialize it out. And then it would be easy for the browsers to write relatively little code to fix it. Now we've got pretty good parsers in the browsers and they understand JSON. But the early kind of quick prototypes, it was really easy on the browser side if it looked like legitimate JavaScript. [COUGH] And so one of the problems was is it was almost underwhelming, the idea that you just take this constant format, the Syntax for JavaScript constants. And you turn it into a standard that says everyone, Javva, C++, C#, C, whatever the server language, you gotta write JavaScript. You're like, I don't know, that's not a standard, you just made that up. He's like, no, JavaScript is as much a standard has anything else, and so he registered json.org. And he talks about this in the interview between him and me. And he registered json.org and he wrote up a document that is JSON. Unlike most standards, it wasn't a government funded, it wasn't a standards organization like IEEE, or ANSI, or anything like that. It was just Doug Crockford, did it, wrote it. And it was such a good idea that people just started using it and they referred to json.org. Now, there's a subtle difference between JavaScript constant format and JSON, partly because you can put variables in the JavaScript. And so he simplified it, and so he kind of made it a subset of the JavaScript constant format or the constant syntax. And so this is what it looks like. It looks like a dictionary and list, or in JavaScript terms, an object and arrays. And so you have key-value pairs, like name maps to Chuck, age maps to 29, college is true. You can have numbers, you can have Booleans, but you can have nesting. So you can have, inside of an object, you can have one of the attributes that points to a list of two strings. And then you can have an attribute inside the outer object, the outer object being who here, that has itself an object. And so for example, if I wanted to get to this 10, I would say who.skills.C, and that would reference that number 10. And so that's just an object that has an attribute that itself is an object. And then that's an attribute of the inter object. So that's the basic JSON syntax, and it's pretty easy. I mean, [LAUGH] I rarely have to look it up, right, because it's so intuitive. And so that's one of the things that a lot of people really like about the JSON syntax. And so here we have the JSON syntax, and it's in JavaScript. So that exact same text, I just am going to write it, who equals, and then I'm going to console log to who variable, and then out it comes. Okay, so it is really, that's also, this part here is also completely legitimate JSON to send across between a client and server using AJAX, and that's cool. But it's also really and totally a legitimate JavaScript constant. Like I said, there are things you can do in JavaScript you're not allowed to do in JSON. So when there's a view, and it's got to produce some JSON, well, you're going to to go to some URL and then you're going to map that URL to some view. And in this case, I'm just going to do a get request. And so I'm not going to use a class, I'm just going to use a function base. And in this particular case, I'm going to import JSON response. And JSON response is, JSON response is like HTTP response, but instead it's known to be JSON. And so the time sleep makes it so that when I run this, it pauses for a second so I can watch as it comes back. That's not what you would normally do. Then I have a little dictionary, and that dictionary just is, this is a Python dictionary, a key-value pair, it happens to look like JSON. And then I basically say serialize that and send it back. Now, there's other things that have to happen. So this is just a standard, I could have made that a list. It's best practice in JSON for the outer thing to be an object. And so if you have a list, you have that as a attribute of the outer object. So you tend to want to make the thing that you pass back on JSON response an object or dictionary rather than list. And so if you have a list, you put it inside of a dictionary. Okay, and so that's going to send that back. So if we were to hit this and just go to it in a browser and go to jsonfun. And this browser that I happen to be taking the screenshot sort of can show the raw data, which is just this is the JSON. Now, it looks like the dictionary, but it's not, this is a serialized JSON thing, it looks like the dictionary. And you can see that's exactly what came back from that browser, from that server. But then if you look at it parsed with JSON, and the browsers kind of know how to parse JSON. And so it looks up the curly braces and the single quotes. And it basically says, this would make a JavaScript object, where the first attribute is mapped to first thing and the second attribute is mapped to second thing. So browsers increasingly just know what JSON looks like. And so for debugging, we get to see this, and it's kind of nice. Now, the other thing that you would notice if you look really closely is if you took carefully a look at the headers, you'll see that the content type is application/json. We've done a whole bunch of things, text/html, we've done text/plain, we've got an image/png, I don't know if you've done application/pdf or not. But application/json is how we tell the browser that this is going to be JSON. And when we send a JSON response back from a view, that's what indicates to send this content type on the HTTP response protocol. And so that way, the browser knows that it's getting JSON and not plain text, and not HTML, and not a PNG. So up next, we're going to take this and turn it into a simple chat application. [MUSIC]
