- Define a client and server
- Explain what an HTTP request is
- Explain the nature of request and response
- Define a static site vs. a dynamic site
How many times a day do you use the internet? How many times do you load a different web page? Think about how many times you do this in a year! As a user, all you really need to know is the URL to navigate to. You don't need to concern yourself with what's going on behind the scenes. But if you want to be a web developer, it's important to have some understanding of how the web works. From here on out, you are no longer just a user of the internet. You are a creator of the web.
So seriously, how does this:
https://www.youtube.com/user/AdeleVEVO
Turn into this:
The internet operates based on conversations between the client (more familiarly known as the browser) and the server (the code running the web site you're trying to load). By typing in that URL into your browser, you (the client) are requesting a web page. The server then receives the request, processes it, and sends a response. Your browser receives that response and shows it to you. These are the fundamentals of the web. Browsers send requests, and servers send responses. Until today you have always been a client. Moving forward you will be building the server. This means processing requests, creating responses, and sending them back to the client.
We will be writing our servers using Ruby and a few different frameworks. But your browser doesn't know, nor does it care, what server it talks to. How does that work? How can a server that was written 15 years ago still work with a browser written 15 months or days ago?
In addition, you can use multiple clients! You can use Chrome, Safari, Internet Explorer, Opera, and many others. All of those browsers are able to talk to the same server. Let's take a closer look at how this occurs.
Being able to switch out both the server and the client happens because the way browsers and servers talk is controlled by a contract or protocol. Specifically it is a protocol created by Tim Berners-Lee called the Hyper Text Transfer Protocol or HTTP. Your server will receive requests from the browser that follow HTTP. It then responds with an HTTP response that all browsers are able to parse.
HTTP
is the language browsers speak. Every time you load a web page, you are
making an HTTP
request to the site's server, and the server sends back an
HTTP
response.
In the example above, the client is making an HTTP GET request
to YouTube's
server. YouTube's server then sends back a response and the client renders the
page in the browser.
When you make a request on the web, how do you know where to send it? This is done through Uniform Resource Identifiers or URIs. You've probably also heard these referred to as URLs. Both are fine. Let's look at the URI we used up top.
http://www.youtube.com/user/adelevevo
This URI is broken into three parts:
http
- the protocolyoutube.com
- the domain/user/adelevevo
- the resource
The protocol
is the way we're sending our request. There are several different
types of internet protocols (SMTP for emails, HTTPS for secure requests, FTP for
file transfers). To load a website, we use HTTP.
The domain name
is a string of characters that identifies the unique location
of the web server that hosts that particular website. This will be things like
youtube.com
and google.com
.
The resource
is the particular part of the website we want to load. YouTube
has millions and millions of channels and videos, so we need to identify the
specific resource we want: /user/adelevevo
(because we can't get Hello out of
our heads).
An analogy that works well is an apartment building. The domain is the entire
building. Within that building, though, there are hundreds of apartments. We use
the specific resource (also called a path) to indicate that we care about
apartment 4E. The numbering/lettering system is different for every apartment
building, just as the resources are laid out a bit differently for every
website. For example, if we search for "URI" using Google, the path looks like
this: https://www.google.com/search?q=URI
. If we use Facebook to execute the
same search, it looks like this: https://www.facebook.com/search/top/?q=uri
.
When making a web request, in addition to the path, you also need to specify the action you would like the server to perform. We do this using HTTP Verbs. We can use the same resource for multiple actions, so it is the combination of the path and the HTTP verb that fully describes the request.
GET
requests are the most common browser requests. This just means "hey
server, please GET me this resource", i.e., load this web page. Other verbs are
used if we want to send some data from the user to the server, or modify or
delete existing data. Below is a list of the available HTTP Verbs and what each
is used for. We will learn about them a bit later:
Verb | Description |
---|---|
HEAD | Asks for a response like a GET but without the body |
GET | Retrieves a representation of a resource |
POST | Submits data to be processed in the body of the request |
PUT | Uploads a representation of a resource in the body of the request |
DELETE | Deletes a specific resource |
TRACE | Echoes back the received request |
OPTIONS | Returns the HTTP methods the server supports |
CONNECT | Converts the request to a TCP/IP tunnel (generally for SSL) |
PATCH | Apply a partial modification of a resource |
Our client so far has made a request to YouTube's server. In this case, a
request to /user/adelevevo
. The server then responds with all the code
associated with that resource (everything between <!doctype html>
and
</html>
), including all images, CSS files, JavaScript files, videos, music,
etc.
When the client makes a request, it includes other items besides just the URL in the "headers." The request header contains all the information the server needs in order to fulfill the request: the type of request, the resource (path), and the domain, as well as some other metadata. The request header would look something like this:
Once your server receives the request, it will do some processing (run code you wrote!) and then send a response back. The server's response is separated into two sections: the headers and the body.
The server's response headers look something like this:
The headers contain all of the metadata about the response. This includes things like content-length (how big is my response) and what type of content it is. The headers also include the status code of the response.
The body of the response is what you see rendered on the page. It is all of that HTML/CSS that you see! Most of the data of a response is in the body, not in the headers.
The primary way that a human user knows that a web request was successful is
that the page loads without any errors. However, you can also tell a request was
successful if you see that the response header's status code is 200
. You've
probably seen another common status code, 404
. This means "file not found."
Status codes are separated into categories based on their first digit. Here are the different categories:
- 100's - informational
- 200's - success
- 300's - redirect
- 400's - error
- 500's - server error
There are a number of other status codes and it's good to get familiar with them. You can see a full list of status codes on Wikipedia.
It's important to note that there are two different types of websites: static
and dynamic. A static
website is one that doesn't change unless a developer
opens up an HTML file and modifies the content of that file. Dynamic
websites
are sites where the content changes based on user input (e.g. Facebook, Twitter,
Yelp, etc.). Every time you visit the site, the content you see is most likely
different than the last time you visited because someone else gave a review of
that restaurant, or sent out a new tweet, or commented on that image you liked.
It can be helpful to think of static sites as "websites" and dynamic sites as "web apps", although there is no official definition of either term or the difference between them. The terms provide a convenient way to distinguish in a non-technical way between sites with static vs. dynamic content.
The flow of request and response is slightly different for a static website than for a dynamic web app. When the client wants to load a static site, the client makes a request, and the server finds the file on a disk and sends it back. Done and Done.
It gets a little bit more complex with a web app. The client makes a request, the server runs application code (think of this as your Ruby code), and returns a dynamically generated response.