[MUSIC] The next web technology we will learn about is Hypertext Transfer Protocol, which is more commonly referred to as HTTP. Our first clue to understanding HTTP begins with hypertext. Hypertext is a document embedded with hyperlinks, which, when clicked, will take you to the intended document or resource. Originally, hyperlinks were primarily used to link HTML documents. And HTTP was designed to facilitate the use of hypertext and to support the communication of documents and resources expressed in HTML. Now of course, we use hyperlinks to link together multimedia resources, such as images, videos, GIFs, texts, and audio, or documents containing any combination of these. These resources may be static or dynamic. Static resources include files, such as HTML documents, images, or videos. Dynamic resources may be programs that produce some output when they're called. HTTP is a protocol that dictates how information, including hypertext, is transferred across the internet. There are several protocol versions in use, though in this lesson we will base our discussion around HTTP/1.1. Universal Resource Identifiers, URIs, are addresses used to identify resources. And Universal Resource Locators, URLs, are a sub-set of URIs that are used to locate resources. Both are used to identify the resource, but URLs also tell the protocol how to locate and access the resource. URLs provide the protocol and domain name, or IP address, of the machine the resource is stored on and the location of the resource on the machine. So in summary, all URLs are URIs, but not all URIs are URLs. Now let's take a look at an example URI and break it into parts. Suppose, when you open this URI in your web browser you see an image of a sunhat. Here, we can identify the protocol as HTTP, the hostname as etsy.com. The location of the resource on the host machine user/favoriteitems/widebrimsunhat. And finally, the resource itself is sunhat.png. You may be wondering how we are going to locate the resource without an IP address. In fact, we don't explicitly need to be giving the IP address in the URI. Your browser is able to resolve the IP address corresponding to the host name provided in the URI. Either the browser will already know the IP address corresponding to the host name or, if it doesn't know, it will query a Domain Name System, DNS, Server to find out. HTTP is built on top of another protocol called the Transmission Control Protocol, or TCP. TCP allows for reliable, ordered, connection-oriented communication. These desirable properties have resulted in HTTP relying on TCP connections. Specifically, this means that HTTP messages are sent and received through TCP ports. When your browser accesses a URI that starts with HTTP, a connection between your web browser and a web server is opened on TCP port 80, the default port for HTTP messages. Occasionally, you may see a URI that includes a port number. But almost always this is not used because production systems typically use the default TCP ports. If the port number is included, it follows the host name of the site. HTTP is built upon a client/server design. When a client makes a request to a server, this opens a TCP connection between the client and server for them to communicate. In the context of the web, a client/server relationship exists between a web browser and a web server. Now let's look at the general format of HTTP requests and responses. A client request consists of a request line, headers, a blank line, and then sometimes a message body. The request line includes the request method, request URI, and protocol. Optionally, the URI may end in a query string to specify parameter data for the request. This string is separated from the path of the resource by a question mark. The number and kinds of headers included will vary, as many optional headers exist. Mandatory headers allow for the request to be processed. And optional headers can be used to give context to the request. Two headers that must be included in any request are the host header that contains the domain name or IP address of the host and the accept header to inform the server what kinds of content the client will accept as a response. If a message body is present, then a content length header to indicate the size of the body in bytes and a content type header to indicate the type of the body must be included. Following the headers is a blank line, if no message body is required for the request, then the request ends here. Otherwise, if a message body is required for the request, then this is where it goes. The message body may be an HTML document, JSON, encoded parameters, etc. A server response consists of a status-line, headers, a blank line, and then optionally a message body. The status-line includes the protocol version and the HTTP status code, which informs the client the status of the request. There are many possible HTTP status codes, however. If the request has been successfully processed, you will most likely see a status code of 200 OK. Similar to an HTTP request, if a message body is present, then a content length header and a content type header must be included. Other optional headers may be present here. Following the headers is a blank line. If no message body is present in the response, then the response ends here. Otherwise, if a message body is returned in the response, the message body immediately follows the blank line. Just like with HTTP requests, the message body may be an HTML document, JSON, etc. A final note about headers. We've only mentioned a small numbers of the possible headers an HTTP request or response could contain. Many optional headers exist and can be used to provide more information and context about the communication. Next, we need to learn about URL-Encoding. HTTP limits the characters used in URIs, request queries, and request bodies to be ASCII. Special or unsafe characters, like space or Unicode, require you to encode these characters. Usually, unsafe characters are replaced with a percent sign, followed by their two digit hexadecimal digit encoding. An example of an unsafe character is a space. Space is special case in that there are two ways to encode it. We can encode a space using the percent sign followed by 20 or a plus sign. So, to encode multiple words, such as software design and architecture, either of the following would be fine. And to encode query strings, such as color is red and height is very tall, we use the equals symbol to assign each query parameter its value and use the ampersand symbol to join all the parameter value pairs like so. As we learned earlier, each HTTP request must indicate a request method in its request line. HTTP request methods are used to indicate to the web server what it should do with the request. The request methods you are most likely to see are GET, POST, and PUT. The GET method retrieves the resource given by the URI provided in the request line. For example, this could retrieve a webpage, image, or, if a program is specified as the resource, it could retrieve the output of this program. A query string may be sent along with the request in the URI. Queries always start with a question mark and must be URL encoded. No message body is sent along with a GET request. To help understand how this method is used, we will look at an example. Suppose you want to view a campsite reservation you previously made on camping.com. At the time of booking, you were given the reservation number 17021. To review your booking, you must send this URL-encoded query string to camping.com/reservation. Here is the GET request in response. Upon receiving the response, your web browser will render the HTML document it received in the response body. And you will be able to view your reservation on the screen. The POST method is intended to be used to add or modify the resource according to the message body of the request on the host specified in the URI of the request. That is, the message body contains the information that will be used to create or update a resource on the website. HTML forms often use POST requests to submit data. If the data in the message body is from an HTML form, then, like a GET query, it is URL-encoded. Building on the previous example, let's assume your friends have heard about your camping trip and want to come, too. You offer to book their campsite for them. Because you are creating a new reservation on the website, the POST method will be used for this request. The booking information, full name, Mary Teller, email, mteller@gmail.com, reservation date, 01/07/17, and campsite, 35, will be encoded in the body of the request. After receiving and processing the request, the web server sends a response. When the web browser receives the response, it renders the HTML document it received in the message body, allowing you to view your booking confirmation on your computer screen. The PUT method takes the information provided in the body of the request and creates or updates a resource at the location specified in the URI of the request. In other words, the URI specified in the request dictates to the server the identity and location of the enclosed resource. The PUT method is like the POST method in that it can be used to create or update a resource. However, with the POST method, the information contained in the request body is created or updated under an identity and location determined by the web server. Not necessarily the identity and location in the supplied URI. We will again build off of our camping trip example. You realize that you don't have an axe or wood, but would like to have a campfire during your trip. Thankfully, the website allows you to add a note about your reservation for the campsite staff. Since your reservation already exists on the website and you know where to access its information using your reservation number, to add a note you simply need to make a PUT request to that location. The note would be a JSON object and delivered in the body of request. Notice how the content type header has been change to match the type of datas stored in a request body, a JSON object. After the web server processes is the PUT request, in its response it sends an HTML document in its message body. When your browser receives this response, it will render this document for you to see on your computer screen. Now that we have a better idea of how requests are made and handled, let's look at what it means for HTTP to be stateless and the consequences of statelessness. It means that the relationship between requests is not preserved. For example, if you are browsing an online shopping website and clicking on items, the HTTP protocol does not keep track of which items you've previously clicked. Each time you click another item, a new request is sent. But the protocol is not aware if the same client is making the request. A website can use HTTP cookies to track the behavior of shoppers on their site. The first time a client makes a request, the site gives them an HTTP cookie to store information about the client's browsing session. The cookie is stored by the client and updated by the server each time the client makes a request to the server. This allows a server to store state information about interactions with this client, which can be useful for tracking purposes. HTTP is fundamental to how the web works, because it dictates how data is communicated and exchanged. This will be particularly important for invoking and accessing web services and enabling a service-oriented architecture. HTTP uses a client/server relationship to facilitate communication through HTTP requests and responses. With TCP at it's core, HTTP can provide reliable transfer of information.
