Transcript
  • Meteor

What is HTTP?

From the class:  Introduction to DDP

Before we spend time on the DDP protocol, I want to make sure that the HTTP protocol is really clear. So in this video we're going to dive into how HTTP works in a regular web application, and how Meteor first loads up your app. So to do that, I've created a simple HTTP web server here using NodeJS, so let me walk you through it. It just creates a server, and for every request that we get, we're going to send back this string of HTML.

It's just a simple string, an H1 tag that says the item title is whatever it is we passed up in the request. Then we'll listen on port 3,000, and this will tell us that the server's up and running. Let's go over and start the server. On the right is my server code, and since it's a regular node application, I'll start it up with the node command. And we can pass the name of the file, and now our server's running on port 3,000.

In the left, let's start off by using the cURL command line utility to connect to the server. I'll use the dash I flag so that we can see the headers, and we'll make a request to local host 3,000, and I'll name the item, since the server's expecting a name. And let's take a look at what happened here. The client, in this case cURL, sends up a request to the server for a URL item first.

And you can see that URL printed here, so it's just the path from the root, the root being local host 3,000, and then the path being item-first. And the verb that's sent up with the request is a get verb, so every HTTP request has this verb, and then the path to the resource that you'd like to get. So in this case we want to get the resource at location item-first.

So then the server says, OK, I will send back the resource at that location. So it sends back an HTTP response, and we're looking at that response right here. It's just text. The topic contains something called headers, and headers are a way to communicate some key value pairs that the server wants the client to know about, like the fact that the request was responded to successfully with a 200 code. And then the content type of the request response.

And then some other things here, like the date, connection, and the transfer encoding. Then down here we have something called the body of the response, which is, in this case, just text, and it's a special kind of text. It's HTML. So we can see the H1 tag if I just clean this up a little bit. You can see that the text is just an H1 tag that has in it the item title is whatever was passed up. So in this case it's the item first.

And then this entire connection is closed, so for each request we get back a response, and then the request response cycle is complete. Now, if I want to make another request I can do that, and this is simulating hitting the Refresh button in your browser. So we're going to make another request, and notice that on the right there on the server, it's logging that we got another get request from some client asking for the item-first resource.

And we can do that as many times as we want, and each time we do it, each time we make the request from the client, it's a new request, and so the request is sent to the server, the server sends back a response, and then the request response is complete. Now, since we're using the cURL utility, we're seeing that the HTML that's sent back is just text. It's just a string of text, and it's up to the client to decide what to do with that text.

And in the case of the browser, it will take this HTML and render an image to the screen. So let's open up a browser and take a look. As you can see in the browser, when it makes a request to the same resource, when it gets back this text HTML, it knows what to do with it-- namely it renders it or draws it to the page. But we started off with cURL so that you could see that the response that comes back from the server is just text, and it's the browser that's deciding what to do with that text.

And it made the browser a little bit bigger so that we can see that what it's done is render the text to the page, but also create an in memory representation of each of the HTML nodes in JavaScript, so that we can manipulate the nodes using JavaScript. And this is called the Document Object Model, or the DOM. So the HTTP request governs what gets sent back and forth between the client and the server, and then the client, or in this case the browser, can decide what to do with that.

In the previous client, which was cURL, all we did was just print out the response to the screen, but the browser's doing a lot more. It's actually rendering out the HTML to the page, and also creating this document object model in memory so we can manipulate the page using JavaScript. I want to go back to the cURL utility to show you one last really important thing about HTTP, and that's the status code that gets sent back with the response.

So this is called a status code, and it's a key part of the HTTP protocol. What it means is it's a way for the server to tell the client either the request was OK-- that's what 200 means-- or to take some other action. For example, it could send back a 302 header, or a 302 status code, which means that the location for this resource that was requested has changed. And it could provide a location header that says where the new location is.

Or it might send back a status code of 404, which means that the resource that was requested is not found. So there's a whole bunch of status codes, and it's a way for the server to communicate with the client. And I've taken us over to the Wikipedia page showing a list of HTTP status codes in case you want more information. So here you can see that the 200 status code, it means OK, and there's a bunch more in the 200 range.

And then we also looked at the 404, which means not found, and there's a bunch more here in addition to that. Now, one of the benefits of this protocol is it's very simple to understand, and it's stateless, so we just send a request, we get a response, and that's the end of it. But it has some weaknesses. One of those weaknesses is that every time we want some new data, we have to send back the data along with the user interface.

And so every time we move to a different page, we're repainting the entire page with all new HTML. Also, the connection isn't persistent. So if we want to keep a connection open with the server-- for example, if we want the server to notify us of data updates-- there's no way to do that really easily with HTTP. So the DDP protocol allows us to keep a persistent connection opened with the server, and to send data back and forth.

And another tenant of DDP is to not send HTML over the wire like this, but instead just to send data. So instead of rerendering the entire page for each new resource that we want, we can just rerender the parts that have actually changed. So I hope this gave you a good, quick overview of HTTP, and how web applications have traditionally worked.