This video introduces the viewers to HTTP and it focuses on the parts that are used in RESTful APIs.
- [Narrator] In the previous video, we learned about what an API is. In this video we are going to take a look at the various parts of the HTTP protocol that are used by RESTful APIs. First, we will look at the HTTP request and examine the parts that make up a request. This includes a URL path, the HTTP method, the request headers, and the request body. Then, we will look at an HTTP response and learn about the response's status code. An HTTP request is a message that a client sends to an HTTP server. Our web browser sends an HTTP request whenever we navigate to a web page, download a file, or submit a form.
Here, we can see a sample HTTP request that was sent as a result of signing into Packt publishing. On the first line, POST indicates the HTTP method, /index. Html indicates a URL path, and HTTP/1.1 indicates a protocol version that a client is using. The next two lines are the HTTP request headers, and the last line is the request body. So, what are all these fields and what do they mean? First, we will take a look at the URL path. A URL path is an identifier for a server resource.
This can be a static file, a server-side script, or a dynamic webpage. In the old days, this identifier always referenced a file. For instance, this URL path is the path to an image on a server. And the URL path /login.php is the path to a php file on the server. Nowadays, a URL path is an arbitrary string that is parsed on the server. For example, the URL path on my Facebook profile is /salehhamadeh. This does not mean that Saleh Hamadeh is a file on Facebook server.
Facebook server parses the path and dynamically generates the webpage. An HTTP method is a verb that is used on a resource. The four methods that are used by most API's are GET, POST, PUT, and DELETE. Each verb should be used in certain situations. GET is used for retrieving data. Browsers usually add GET requests to the browsing history. So GET requests should not include any sensitive information, such as emails or passwords. POST is used for submitting form data, or sending files to a server. PUT is usually to replace a file on the server, and DELETE is used to delete a file on the server.
In general, GET and DELETE requests do not have a request body, while POST and PUT requests do. Let's look at an example. You open Google Chrome, click on the menu, go to more tools, and go to developer tools. When you click on the network tab to see the requests that are being sent. Let's go to www.packtpub.com, we should start seeing the requests appear here. Let's scroll up and click on the first request. We can see the request method here, in this case it's get.
The next part of an HTTP request is the HTTP headers. HTTP headers are key-value pairs that are sent with requests and responses. They are used to add data to a request. For example, the host header includes the hosting of a website that a client is asking for. It allows servers to host multiple sites on one machine. Another example is a content-length header. The content-length headers tells the receiver the size of the message's body. This is used by web browsers to show us the progress of downloading a file.
The last example is the content-type header. This tells the receiver the format type of the file upfront. When we navigate to a URL to an mp3 file, some browsers will automatically play the music rather than downloading it. These browsers know that the file is a music file while inspecting the content type header. If we go back to our browser, we can see the response header is here, and the request header is here. The host header for this request is www.packtpub.com. The last past of an HTTP request is the request body.
The HTTP body is the message's actual data. This data can be anything that a client wants to send to the server. For example, user equals saleh and password equal chickensandwich is a URL encoded form data to a log in page. Browsers use this encoding by default whenever we submit a form. The next JSON object shows the same data encoded as JSON. This can also be the HTTP body. Now, let's try to log in. We type our email and password, and then we press enter.
Like before, we scroll up and click on the first request, this time we notice that the request method is POST. If we scroll to the bottom, we will see a form data section that has the email and password that we just inputted. If we click on view source, we will see the HTTP body that the browser has sent to the server. Now that we figured out the first half of the puzzle, let's look at the second half. HTTP responses. An HTTP response is very similar to an HTTP request. In fact, an HTTP response has a protocol version, the headers, and the body.
The body usually contains the file content, like html, CSS, or java script. But it can also contain API response data encoded in JSON or XML. The main difference between an HTTP request and an HTTP response is that instead of having a URL path and method, an HTTP response has a status code and a reason phrase. The reason phrase is just the contextual description of the status code. So, what is a status code? A status code is a three digit number that shows the result of handling a request.
The HTTP specification defines over 30 status codes. Status codes that start with a two indicate success. For example, status code 200 corresponds to okay. Web servers send this status code when a requested file was found. Status codes that start with a three indicate redirection. For example, status code 301 corresponds to moved permanently, and is used to tell a client that a file can no longer be accessed using the specified path. Status codes that start with a four indicate a client error.
The most popular status code is 404, which is sent when a requested file cannot be found. Finally, status codes that start with a five indicate a server error. For example, status code 500 is sent when a server has an internal error, like an on call exception. Let's go back to our browser. Here we can see that the status code for this request was a 200 okay. Now, let's try to go to a URL for a resource that does not exist. Lets try blabla.php.
We can see a 404 page, which is what we expected. Now, let's look at this request, the status code is also 404. In this video, we looked at HTTP requests and responses, and we have learned the fields for communicating on this protocol. In the next video, we will learn about how RESTful API's use HTTP to expose data to the outside world.
This Node.js course gives you an overview of a RESTful API and the logical steps of creating one. It explores three different APIs, focusing on their similarities and differences and how to effectively implement one. Instructor Saleh Hamadeh starts off by defining APIs, showing how they can be built on top of HTTP and listing the properties that make an API RESTful. Learn how to develop Twitter Notes, a sample web application that lets users leave notes for their Twitter friends. Use Twitter's API to implement a login flow and then design a web API. Additionally, get a closer look at several other real-world APIs, and learn some best practices to keep APIs secure, maintainable, and efficient.
- Identifying REST resources
- Setting up the development environment
- Consuming a RESTful API
- Creating an OAuth login request
- Getting an access token
- Saving data in MongoDB
- Building a RESTful API
- Testing user-perceived performance
- Looking at APIs in the real world
- Best practices for building RESTful APIs