REST APIs and HTTP

Transcript of the free preview lesson. Remaining lessons unlock with the full course.

Hello, my name is Josh Guardino, and in these lessons you will learn about REST APIs and HTTP. Let's begin by gaining a basic understanding of the HTTP protocol. The HTTP protocol involves the transfer of documents over the internet. These documents may take the form of webpages, JSON, XML, images, videos or anything else that can be sent over the internet. It is a client-server paradigm in which a server sends resources in the form of responses to a client. The client could be a web browser, an API client written in code, or a tool such as Postman. A client is any piece of software that is issuing a request to a server. This would include web APIs and many other types of content. HTTP requests consist of three basic elements of metadata in addition to the HTTP protocol designation, the request method or verb, such as get, post, put, delete, the path, which is the specific resource that the request is trying to reach, in this case here a slash would be the root path, and then the headers, which are key value pairs containing important information about the request itself. Headers are not restricted to requests. Responses also send headers back with the results. HTTP is a stateless protocol. This means that each request to the server is considered a standalone request, and the server does not attempt to associate one request with another request as some types of remoting protocols do in order to allow clients to send multiple messages as part of a larger transaction. The stateless nature of HTTP necessitates the sending of full meta information such as headers each time a request is sent, although there are some mechanisms, such as cookies, that the server can pass back to the client to be sent back to the server in subsequent requests that do provide some contextual information, but this does not change the fact that the protocol is always stateless. HTTP is closely associated with TCP, which is the protocol that governs the transmission of data. TCP is responsible for breaking up data into packets and reassembling them in the correct sequence when received by a server. In my list of collections, I have a category labeled DummyJSON. These DummyJSON services are hosted by dummyjson.com which provides these API endpoints for testing purposes. Unlike the Department of Motor Vehicles API that I'm running locally on my computer, this is a true web-based API. And let's analyze the products path, hosted by dummyjson, using the get method. The URL is https:// then the hostname, and then the path, which in this case would be /products. Contrast this with my local Department of Motor Vehicles API, which has a host name beginning with HTTP without the S. HTTPS is a secure version of HTTP. Because the plain HTTP protocol is inherently insecure, it is quite easy for malicious hackers to eavesdrop on, intercept and modify HTTP requests without the knowledge of the sender. This is why the HTTPS is critical and you should never trust any internet site that does not have the S in the protocol, because messages transmitted back and forth using HTTPS leverage a very secure mechanism called transport layer security or TLS. This ensures that all HTTP messages are encrypted and may only be read by the client and the server. HTTPS and TLS rely on certificates, regardless of whether the client is a web browser, programmatic code, or a software tool, such as Fiddler or Postman. So let's look at the security information for dummyjson.com. The lock icon in my web browser tells me that the site is secure, and by clicking on it the full details of the secure certificate are shown. Clients that connect to HTTPS services should always validate the certificate because certificates are easy to generate in an insecure manner and they have expiration dates. So it's critical for a client to recognize the issuer of the certificate and confirm that it is still valid. In Postman, in the settings, there is a toggle switch for SSL certificate verification, and it is defaulted to off because normally when you are using Postman, you are testing APIs, and not sending or receiving sensitive information. But enabling SSL certificate verification is a good practice, even in an environment such as this, to ensure that messages are always secure. As you can see, the request to the dummyjson.com server is accompanied by a tunneling request on port 443, which is the standard secure port number, and in the inspector I can see all of the information about the certificate and more. Thanks for watching. Stay tuned for the next lesson where I will show you how to use and read HTTP headers.