To really understand how web applications work, you need to have a solid base in the guts of the web.

The lessons of this brief section are designed to make sure you're up to speed on important web concepts. In this lesson, we'll explain how HTTP works and some of the relevant bits that you'll run into when building applications of your own. The next lesson will cover how web servers actually handle HTTP requests and how that relates to your web applications.

We'll revisit some of these topics in a later section on Deployment, where we'll dig deeper into things like server configuration and hosting.

The 10 Second Refresher

You should already remember this, but let's load it up in your short-term memory:

The browser ("Client") communicates with your server by sending HTTP requests and receiving HTTP responses (which typically contain an HTML page but not always).

Thus, HTTP requests are the key link in this whole process. Our work with client-side markup is all in the service of getting the correct requests sent back to the server. Our work with the server is all about handling that request, figuring out what it wants, then sending back a page or payload which presents it.

Got it? Great, let's see what this "HTTP" is all about anyway.

HTTP

HTTP is a protocol which specifies how your browser and web server should communicate. HTTP is a "stateless" protocol, which means that each leg of the request-and-response cycle is treated as a completely independent action.

The request and response each always have a header and usually have a body (some HTTP requests are simply headers). The header contains information about the request or response itself (metadata), including which website to send or return to and what the status of the response is.

Here's a look at HTTP headers for a typical request and response (which you can easily do yourself in Chrome Dev Tools after refreshing the page):

The body of the HTTP request can contain things like data submitted by a form or cookies or authentication tokens, while the response body will usually contain the HTML page you're trying to access.

Here's a look at an HTTP response in Chrome Dev Tools which contains the page's HTML:

The Video

Harvard's David Malan has a practical look at issuing HTTP requests from both the browser and the command line in the following video (just watch ~15-20 mins of it, between roughly 1:11-1:30):

HTTP Verbs

The other key component is that each request uses one of four main HTTP "verbs" -- GET, POST, PUT (PATCH), and DELETE.

These days, you almost only see GET and POST requests (even if you're trying to do a delete of something, they usually fake it using a GET request), but it's important to understand the difference between the verbs. You'll need them to make programmatic requests to other applications via APIs.

GET

A GET request is meant to retrieve a resource from the server and not make any modifications to that resource. Any time you enter a URL in your browser, it will automatically submit it as a GET request that returns the HTML page you've requested. Your browser may then issue a series of GET requests for other useful things like the CSS pages, JavaScript files, and images.

If you need to provide the server with any additional parameters for a GET request, they are appended directly to the URL via the "query string" (so anyone can read them).

Get requests are by far the most common because almost all actions are simply page views, aka requests, for a particular resource like a blog post or a user profile.

POST

A POST request is meant to provide the web server with a new instance of whatever resource is indicated by the URL path (so it is a potentially "unsafe" request). The HTTP request typically contains information about the resource you're trying to send the server inside its body (which means that you can't read this information without "opening up" the request).

A typical case for a POST request is when you've submitted a form and are sending the server information that it should add to the database.

Web browsers typically will not send requests beyond GET and POST, so the following requests are usually faked by using clever parameters and then converted by your web application into their original form for routing purposes within the application.

PUT (PATCH)

A PUT request is meant to either create a new resource with the enclosed data or store (add) the enclosed data under the existing resource specified by the URL.

If an existing resource is simply being modified but not added to, the similar PATCH request is used.

DELETE

A DELETE request asks the server to remove the resource specified by the URL. Browsers are typically configured to not submit these requests but, like PUT/PATCH requests, they're perfectly valid for API calls.

HTTP Status Codes

When an HTTP response is returned, one of the header fields is the Status Code. This helps your browser figure out whether the resource was found and can be displayed or whether it should redirect you, try again, or display an error page.

Here's what HTTP status codes look like in Chrome Developer Tools:

The most common codes (which you'll see A LOT) are provided below:

• 200: Everything's fine! We found what you wanted and sent it over.
• 301: Moved permanently. Check the "Location" field for where you should really go from now on (so update your browser not to come back here)...
• 302: Temporarily moved. Check the "Location" field for where you should head now (but try again here later)
• 304: The resource was found but hasn't changed from the version in your cache so we didn't include it in the response body.
• 400: Bad request. Your syntax or something else is off and the server couldn't figure out what you're talking about.
• 401: Unauthorized request. We understood you but you can't do that. We'll give you the option of trying again and submitting the proper credentials along with your request.
• 403: Forbidden. We understood but are refusing to comply and you shouldn't try again.
• 404: Not found. We understood but couldn't seem to locate what you were looking for.
• 500: Internal Server Error. The request was never completed because the server broke midway through.

See the REST API Tutorial for a comprehensive list of status code explanations.

URLs

You know all about HTTP but what are the actual components of the URL that specifies which resource we're trying to access? How do you attach parameters to a GET request? Which part is the host? The protocol (aka scheme)? The path?

Deconstructing the URL https://www.google.com/search?q=what+is+a+url:

PROTOCOL: https

You'll often see the TCP/IP protocols of http, https and occasionally ftp (when transferring files).

SUBDOMAIN: www

This is the most common but many domains also are set up to handle just the TLD, e.g. http://vikingcodeschool.com. Other common subdomains include blog.example.com or mail.example.com, each of which will route to separate web application.

TOP LEVEL DOMAIN: .com

You're also probably familiar with others like .org, .edu and .gov.

PATH: /search

Whereas the other stuff is used to find your web application in the first place on the wide world of the Internet, this portion of the URL tells the web application where to route the request within itself.

PARAMETERS: q=what+is+a+url

Storing parameters in the URL itself only happens for GET requests (others put it directly into the body of the HTTP request). Once your app has routed the request within itself using the PATH, you'll use these parameters to figure out what to actually do (e.g. which post to retrieve).

Once you understand what these components are, you can easily use Ruby's libraries to help you build your own URLs and send requests. You also run into specific pieces like the "path" and "parameters" again and again when using web frameworks.

Diving Deeper

If you want to dig in a bit deeper (which is optional), Ode to Code's HTTP guide is a good start.

Wrapping Up

Hopefully, you've got a good overview of how HTTP works and the relevant bits that you'll be working with through the end of the course. In the next lesson, we'll continue the chain by talking about how a web server works to grab an incoming HTTP request.

• Back to Basics: HTTP Basics from ThoughtBot
• HTTP Request/Response Basics from DevHub
• Web TCP/IP protocols from W3 schools
• http://web-sniffer.net/ lets you grab HTTP requests from specific websites -- fun for playing around with.
• HTTP explained by Harvard's David Malan is comprehensive and covers pretty much everything on the web.
• URL Definitions from Matt Cutts on how Googlers pick apart URL components
• REST API Tutorial contains HTTP status codes.
• HTTP Status Codes

Sorry, comments aren't active just yet!