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.
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 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:
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):
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.
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.
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.
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.
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.
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:
See the REST API Tutorial for a comprehensive list of status code explanations.
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
You'll often see the TCP/IP protocols of
https and occasionally
ftp (when transferring files).
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
mail.example.com, each of which will route to separate web application.
You're also probably familiar with others like
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.
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.
If you want to dig in a bit deeper (which is optional), Ode to Code's HTTP guide is a good start.
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.