So let's take a minute to talk about an HTTP request in your browser. Now I'm on Google.com which is going to enforce SSL, so you will see HTTPS is the protocol. We see colon slash slash and then our domain.
Now if you open up in Chrome the developer tools — you can do this in Safari and Firefox in any browser as well — if we refresh the page and look at the Network tab we'll see all of the requests that are made when we visit this page. The very first one is a GET request to Google.com and we got a 200 response which means it was a success.
So if we click on this we can see the details of this request. So with Google we are on HTTPS which the browser understands. HTTP and HTTPS those are specific ports, so HTTP goes on port 80 by default. In HTTPS SSL goes on port 443 by default. So when you give it a domain you're going to get this converted to a remote address which is 127.217.4.196. That's Google's IP address that we used to get this web page.
Then we got port 443 here because we were using HTTPS and we got a successful response.
HTTP methods and response headers
When you're in your browser you can make multiple types of requests. There is a GET request which says, 'Hey, go give me a page that I would like to look for.' There's POST requests which say, 'Here we're going to send data to Google' — so when you log in you're going to make a POST request to log in with your email and your password for example. There are other requests that are like PUT or a PATCH which allow you to update things like change your email or your password and that will work on an existing database record somewhere in Google servers. And then there's also a DELETE request, so if you want to delete your account you can say let's delete this object.
So Google server gives us a response with a bunch of headers that include cookies. You can see those here as Set-Cookie, and we have the other headers here for caching and the content type and the time and those sorts of things. And we can see here the request headers that we sent over. We want to go to Google.com, we want to use HTTPS. We will accept an HTML response or XML or images and so on. Google reads all of these headers and then gives us a response back.
Comparing Google and local Rails requests
Google's response is an HTML document where they've really compressed a lot of JavaScript and things very tightly in their response so they can send that to people very, very quickly. So if we go to our Rails application and we open up the Network tab here and we refresh the page we'll see the Rails request and response.
So this is 127.0.0.1 and that is our request to our local Rails server. 127.0.0.1 means go talk to your own computer on port 3000. And you also will see this as localhost — that's the same thing and it will give you the same response there.
Now if we open this up we'll see that we get the same sorts of things here. We have a response and a request and you can see what all is defined there and the response HTML as well. So we have two separate things. In our request we have the URL — we have the URL that we're looking for — and then we have our headers which are cookies, they're cache-control things, and so on. And then there are the body of the response which is your HTML, your CSV, your XML, your image — whatever the server is responding with. So you want to keep this Network tab open to monitor what's going on.
But what's really nice is that if you go into the Rails logs you'll see here the exact same stuff but from the server side of things. So in your browser you can see what it is asking for and then on the server you can see how Rails is responding to that request.
HTTP as a simple text protocol and caching basics
So here we got a GET request to retrieve a page for the default route which is the route just the slash by itself. That is the root route and Rails decided to process this with the Rails welcome controller and the index action and it's looking for an HTML response so it gave us these two templates as HTML and returned that with a success 200 in one millisecond so it was very fast and gave us that response very, very quickly.
Before we dive into Rails I want to point out that your requests in your browser are very simple. They're actually just these messages sent back and forth to your server from your browser and they're just text. And so the protocol is that you have your GET, your URL that you want and then the HTTP protocol 1.1 in this example, and we're going to ask, for example, example.com to give us their root route which is just the slash. And so it's just text being sent from your browser to a server — nothing to it. It's very simple and your server will do a little bit of work and then generate this response and send it back and it's going to give you the same things but kind of in reverse.
So it's going to say HTTP/1.1 you got a 200 OK response so it was successful. Here are your headers. We're going to tell you when you requested it and your content type which tells the browser, 'Hey, this is HTML so you can render that out.' The amount of content, so just so that your browser knows, we give you 155 bytes so if you ever didn't receive all of that you would be aware of it. This is the last time it was modified so 2003 — very long time ago — and your browser can understand to use some of these other headers like the ETag and say, 'Hey, go cache this response and if you ever make this request again you don't need to — if we've got the same ETag we can cache that in your browser.' So your browser can say, 'Hey, let's load the version we have cached and then go check if there's a new one.' Oh, there's not — we'll just leave it and we're done. So it can do things very fast like that.
Then after the headers and the HTTP response type it will just give you some HTML back for this example. The Wikipedia article on this covers all kinds of things like authentication and other stuff that HTTP does, but for our example we're going to be doing something very simple and we want to focus more on Rails. So HTTP is something you definitely want to understand at a high level because that is where all of your requests and Rails are generally going back and forth between your browser and your Rails app. So it's important to understand the protocol that they use to talk between each other and Rails will abstract a lot of that out to make it easier for you. But if you don't understand what's happening underneath then it can be very hard to debug problems. So that is a quick introduction to it. Definitely recommend reading up on it some more on your own — the MDN guides from Mozilla are phenomenal and the Wikipedia page for HTTP is actually pretty good too. It covers quite a bit of stuff.
In the next video we're going to talk about MVC or Model-View-Controller which is how Rails organizes your application to respond to HTTP requests.
