In this course, we will learn the fundamentals of the Hypertext Transport Protocol (HTTP) by exploring several popular HTTP APIs such as the GitHub API. Starting with the basic structure of an HTTP request and response, we will then delve into the specifics of each element of the request/response messages. Using concrete examples from these APIs, we will cover request methods, response status codes, messages headers, and message bodies. Along the way, you'll learn about specific message headers, such as
Cookie and how they control the behavior of clients/browsers and HTTP API services.
This course uses HTTPie, if you would like to follow along with the instructor you can download the client here.
Let's look at several HTTP requests to learn the basic structure of these messages, and how the various elements communicate important information from the client/browser to the API service.
Follow the instructions at HTTPie to download the CLI tool and follow along.
The body of an HTTP request or response can serve many functions, from including the input data to a POST request, to returning varied representations of a resource in response to a GET request. This lesson details how message bodies are handled in requests and responses, and the associated HTTP headers that provide metadata about the included message body.
The HTTP GET & HEAD methods are used to retrieve information about a resource. The GET method will retrieve the metadata about the resource, encoded in the HTTP headers, as well as a representation of the resource itself in the message body (e.g. a JSON document with fields that describe a user). The HEAD method behaves like GET, but only retrieves the status and headers; this can be useful when you need some metadata about a resource (e.g. the Last-Modification time), but don't want to waste time or bandwidth fetch the resource itself in the message body. Finally, we discuss the idempotent and safe natures of these HTTP methods.
The 2xx family of status codes are used in HTTP responses to indicate success. Beyond the generic
200 OK status code, there are a set of more specific success status codes that provide additional context or details about the specific nature of the successful request/response. We will explore the available success status codes, and what additional information they convey.
The 3xx family of status codes are used in HTTP responses to inform the client/browser should look somewhere else for the requested resource. Most often, this is used to indicate a resource is temporarily or permanently found at a new URL, but it may also be used to inform the client that the client’s own cache is the other location where the requested resource can be found. We will explore the available redirection status codes, and what additional information they convey.
The 4xx family of status codes are used in HTTP responses to inform the client/browser of an error relating to the user’s request. The status codes in this family are intended to indicate a problem that should be possible to fix or remedy by the user or developer. For example, a 401 Unauthorized status code lets the user/developer know they need to provide authorization information with their request; should they re-submit the request with the additional authorization header, the request may succeed. We will explore the available client error status codes, and what additional information they convey.
The 5xx family of status codes are used in HTTP responses to inform the client that the server experienced an error. The status codes in this family are intended to indicate server or network errors that do not pertaining to a problem with client or the client’s request. For example, a response with a 503 Service Unavailable status code is unlikely to be resolved by resubmitting the request with different content type or additional headers. We will explore the available server error status codes, and what additional information they convey.
The HTTP POST method is used to request the resource process the included request message body representation according to resource specific semantics. HTTP POST is loosely defined by definition, and can be used in many different scenarios, such as creating a new resource based on the request representation, appending data to an existing representation, or generic processing of an HTML form submission. Due to the nature of POST performing arbitrary resource specific processing, it is considered neither ‘safe’, nor ‘idempotent’.
The HTTP DELETE method is used to request that the server perform a delete operation on the specified resource with resource specific semantics. Behind the scenes, the delete operation may result in a removal of a file from the filesystem, or an update to the database to reflect the change. Because multiple requests to delete the same resource has the same effect as a single one, the DELETE method is considered ‘idempotent’, but not considered safe.
The HTTP PATCH method is used to make modifications to existing resources. In particular, it is designed for "partial updates", as opposed to replacing an entire resource using the HTTP PUT method. Although certain HTTP PATCH requests may behave idempotently, this is not true of all possible PATCH requests, so this request method is not idempotent, nor considered safe. The request body of a PATCH request may be simple
application/json, or a more specialized type, such as
The HTTP OPTIONS method is used to request information about the communication options available for the target resource. The response may include an Allow header indicating allowed HTTP methods on the resource, or various Cross Origin Resource Sharing headers. The HTTP OPTIONS method is both safe and idempotent, as it is intended only for use in querying information about ways to interact with a resource.