Learn how to set up an HTTP server with Node.js.

Setting up a Server with HTTP

While we have encountered simple examples of servers handling HTTP requests, some requests require a bit more work than returning a simple string such as `'Hello World'`. In real-world applications, servers are responsible for helping to persist and retrieve data, usually through interaction with a database.

Databases are remote resources to which the server must make a request. When this happens, the server making the request functions as the client, sending HTTP messages to the database server. Databases usually have their own Software Development Kits (SDKs) and Object-Relational Mapping (ORMs) that can be used to connect to them easily. But with the right information, requests could potentially be made in a raw form directly from your server using something like the HTTP `.request()` method.

![Server to database diagram](https://static-assets.codecademy.com/Courses/Learn-Node/http/data-web-flow.png)

As seen in [the diagram](https://static-assets.codecademy.com/Courses/Learn-Node/http/data-web-flow.png) above, a single server often does not represent the final destination in processing a request from a client. Instead, a client sends a request, which is then processed partially, generating a separate HTTP request from the server to the database. When received, the server waits for the database's response and will ultimately relay that information as a response back to the original caller.

Interacting with a Database

HTTP requests and responses have specific structures to help facilitate the exchange of information between a client and a server. These structures encapsulate all of the important information required to instruct the recipient of the message on how to react.

#### Requests

Requests are comprised of a few core elements that provide information to a server. The core elements that can be expected are:

1) **HTTP Method**: The HTTP method is usually a verb, such as `GET` and `POST`, or a noun such as `OPTIONS` and `HEAD`. These methods inform the server of the intent of the request and are used in accurately routing and processing requests. For instance, an HTTP request containing a `GET` method implies that the client wants to fetch a resource. The list of supported HTTP methods can be found using the `http.METHODS` property.

2) **Path**: The path denotes the path of the resource relative to the root URL. For example, making a `GET` request to `https://codecademy.com/api/lessons` would strip common elements such as the protocol (`https://`) and domain (`codecademy.com`), leaving the path of `/api/lessons`.

3) **HTTP Protocol Version**: The version of the HTTP protocol (I.e. [HTTP/1.1](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol), [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2), and [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3)). We will learn more about this in the next exercise.

4) **Headers**: Headers are optional and are used to convey additional information that may be important in processing a request by a server. There is an extensive list of [standard headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) that can be used, as well as custom headers that can be added on a per-application basis.

5) **Body**: The body contains data required to be sent to the server to process a request. The body is not leveraged for all request types. It is most common to see a body attached to requests with verbs such as `POST`, `PUT`, and `PATCH`.

#### Responses

Responses are comprised of similar elements to their counterpart requests, with a few differences. The core elements that can be expected in a response are:

1) **HTTP Protocol Version**: The version of the HTTP protocol, similar to the request.

2) **Status Code**: The status code indicates if the request was successful and, if not, why it wasn't successful.

3) **Status Message**: The status message provides a short description of the corresponding status code.

4) **Headers**: These response headers are similar to those provided in a request.

5) **Body**: The body of a response contains data corresponding to the fetched resource. The body is optional and contains data only when necessary to fulfill the request.

Diagram showing contents of an HTTP response and request

The Structure of HTTP

Once a request is processed, a response must be returned to the client to inform it of what happened. To build a response for the client, several pieces of information are required. One of these pieces of information is the [HTTP response status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status), which is responsible for indicating whether a specific HTTP request has been successfully completed.

Response status codes are grouped into five classes:

1) [Informational](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#information_responses): Range from `100` to `199`.

2) [Successful](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#successful_responses): Range from `200` to `299`.

3) [Redirects](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages): Range from `300` to `399`.

4) [Client Errors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses): Range from `400` to `499`.

5) [Server Errors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses): Range from `500` to `599`.

Each response status code conveys information about what happened during the processing of the request, which in turn helps the client decide how to handle the response and if further action is necessary. Status codes are paired with a short text-based description to help elucidate the meaning of the code. Some common types of status codes that you are likely to encounter are `200 OK`, `400 Bad Request`, and `500 Internal Server Error`. 

HTTP Status Codes

Typically, an HTTP server will require information from the request URL to accurately process a request. This request URL is located on the `url` property contained within the `req` object itself. To parse the different parts of this URL easily, Node.js provides the built-in [`url` module](https://nodejs.org/api/url.html). The core of the `url` module revolves around the `URL` class. A new `URL` object can be instantiated using the `URL` class as follows:

```js
const url = new URL('https://www.example.com/p/a/t/h?query=string');
```
Once instantiated, different parts of the URL can be accessed and modified via various properties, which include:

* `hostname`: Gets and sets the host name portion of the URL.
* `pathname`: Gets and sets the path portion of the URL.
* `searchParams`: Gets the search parameter object representing the query parameters contained within the URL. Returns an instance of the [URLSearchParams](https://nodejs.org/docs/latest-v14.x/api/url.html#url_class_urlsearchparams) class.

You might recognize the `URL` and `URLSearchParams` classes if you are familiar with browser-based JavaScript. It's because they are actually the same thing! These classes are defined by the [WHATWG URL specification](https://url.spec.whatwg.org/). Both the browser and Node.js implement this API, which means developers can have a similar developer experience working with both client and server-side JavaScript.

Using these properties, one can break the URL down into easily usable parts for processing the request.

```js
const host = url.hostname; // example.com
const pathname = url.pathname; // /p/a/t/h
const searchParams = url.searchParams; // {query: 'string'}
```
While the `url` module can be used to deconstruct a URL into its constituent parts, it can also be used to construct a URL. Constructing a URL via this method relies on most of the same properties listed above to set values on the URL instead of retrieving them. This can be done by setting each of these values equal to a value for the newly constructed URL. Once all parts of the URL have been added, the composed URL can be obtained using the `.toString()` method.

```js
const createdUrl = new URL('https://www.example.com');
createdUrl.pathname = '/p/a/t/h';
createdUrl.search = '?query=string';

createUrl.toString(); // Creates https://www.example.com/p/a/t/h?query=string
```

The URL Module

To process HTTP requests in JavaScript and Node.js, we can use the built-in [`http` module](https://nodejs.dev/en/api/v19/http). This core module is key in leveraging Node.js networking and is extremely useful in creating HTTP servers and processing HTTP requests.

The `http` module comes with various methods that are useful when engaging with HTTP network requests. One of the most commonly used methods within the `http` module is the `.createServer()` method. This method is responsible for doing exactly what its namesake implies; it creates an HTTP server. To implement this method to create a server, the following code can be used:

```js
const server = http.createServer((req, res) => {
  res.end('Server is running!');
});

server.listen(8080, () => {
  const { address, port } = server.address();
  console.log(`Server is listening on: http://${address}:${port}`);
})
```

The `.createServer()` method takes a single argument in the form of a callback function. This callback function has two primary arguments; the request (commonly written as `req`) and the response (commonly written as `res`).

The `req` object contains all of the information about an HTTP request ingested by the server. It exposes information such as the HTTP method (`GET`, `POST`, etc.), the pathname, headers, body, and so on. The `res` object contains methods and properties pertaining to the generation of a response by the HTTP server. This object contains methods such as `.setHeader()` (sets HTTP headers on the response), `.statusCode` (set the status code of the response), and `.end()` (dispatches the response to the client who made the request).  In the example above, we use the `.end()` method to send the string 'Server is Running!' to the client, which will display on the web page.

Once the `.createServer()` method has instantiated the server, it must begin listening for connections. This final step is accomplished by the `.listen()` method on the server instance. This method takes a [port](https://en.wikipedia.org/wiki/Port_(computer_networking)) number as the first argument, which tells the server to listen for connections at the given port number. In our example above, the server has been set to listen on port `8080`. Additionally, the `.listen()` method takes an optional callback function as a second argument, allowing it to carry out a task after the server has successfully started.

Using this simple `.createServer()` method, in conjunction with the callback, provides the ability to process HTTP requests dynamically and dispatch responses back to their callers.

The HTTP Module

To process and respond to requests appropriately, servers need to do more than look at a request and dispatch a response. Internally, a server needs to maintain a way to handle each request based on specific criteria such as `method`, `pathname`, etc. The process of handling requests in specific ways based on the information provided within the request is known as *routing*.

The `method` is one important piece of information that can be used to route requests. Since each HTTP request contains a `method` such as `GET` and `POST`, it is a great way to discern different classes of requests based on the action intended for the server to carry out. Thus, all `GET` requests could be routed to a specific function for handling, while all `POST` requests are routed to another function to be handled. This also allows for the logical co-location of processing code with the specific verb to be handled.

```js
const server = http.createServer((req, res) => {
  const { method } = req;

  switch(method) {
    case 'GET':
      return handleGetRequest(req, res);
    case 'POST':
      return handlePostRequest(req, res);
    case 'DELETE':
      return handleDeleteRequest(req, res);
    case 'PUT':
      return handlePutRequest(req, res);
    default:
      throw new Error(`Unsupported request method: ${method}`);
  }
})
```

In the above example, the HTTP `method` property is [destructured](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) from the `req` object and used to conditionally invoke a handler function built specifically for handling those types of requests. This is great at first glance, but it should soon become apparent that the routing is not specific enough. After all, how will one `GET` request be distinguished from another?

We can distinguish one request from another of the same method through the use of the `pathname`. The `pathname` allows the server to understand what resource is being targeted. Let's take a look at the `handleGetRequest` handler function.

```js
function handleGetRequest(req, res) {
  const { pathname } = new URL(req.url);
  let data = {};

  if (pathname === '/projects') {
    data = await getProjects();
    res.setHeader('Content-Type', 'application/json');
    return res.end(JSON.stringify(data));
  }

  res.statusCode = 404;
  return res.end('Requested resource does not exist');

}
```

Within the `handleGetRequest()` function, the `pathname` is being checked to match a known resource, `'/projects'`. If the `pathname` matches, the resource data is fetched and then subsequently dispatched from the server as a successful response. Otherwise, the `.statusCode` property is set to `404`, indicating that the resource is not found, and a corresponding error message is dispatched. This pattern can be extrapolated to any number of conditional resource matches, allowing the server to handle many different types of requests to different resources.

Routing

Just like with databases, sometimes servers need to make requests to external APIs to accomplish some goal. There are a variety of reasons to reach out to external services. Some common situations are payment processing, service integrations with other products, webhooks, and so on.

There are a few methods provided by the `http` module that facilitate making HTTP requests to external services. One of these methods is the `request()` method. The `request()` method takes two arguments; it takes a configuration object containing details about the request as well as a callback to handle the response.

```js
const options = {
  hostname: 'example.com',
  port: 8080,
  path: '/projects',
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
}

const request = http.request(options, res => {
  // Handle response here
})
```
For convenience, the `http` module provides a convenient method for making `GET` requests in the form of the `get()` method. This method differs from the `request()` method in that it automatically sets the method to `GET` and calls `req.end()` automatically.

The fact that servers can make HTTP requests to other services opens up possibilities for different architecture designs for back-ends. One example of an architecture made possible by this ability is [microservice architectures](https://en.wikipedia.org/wiki/Microservices). Microservice architectures divide needs into separate lightweight services that communicate via HTTP over a network. As such, a single application can be comprised of dozens of microservices, which could all be written in different programming languages, but work together by communicating over HTTP.

![microservice diagram](https://static-assets.codecademy.com/Courses/Learn-Node/http/microservices.png)

Interacting with Another Backend API

While the `url` module can handle query strings attached to URLs, it can also be done with the built-in [`querystring` module](https://nodejs.org/api/querystring.html#querystring_querystring_decode). The `querystring` module is dedicated to providing utilities solely focused on parsing and formatting URL query strings. As such, the module provides a much smaller number of methods to use. The core methods are listed below:

* `.parse()`: This method is used for parsing a URL query string into a collection of key-value pairs. The `.decode()` method does the same.
```js
const str = 'prop1=value1&prop2=value2';
querystring.parse(str); // Returns { prop1: value1, prop2: value2}
```
* `.stringify()`: This method is used for producing a URL query string from a given object via iteration of the object's "own properties." The `.encode()` method does the same.
```js
const props = { "prop1": value1, "prop2": value2};
querystring.stringify(props); // Returns 'prop1=value1&prop2=value2'
```
* `.escape()`: This method is used for performing [percent-encoding](https://developer.mozilla.org/en-US/docs/Glossary/percent-encoding) on a given query string.
* `.unescape()`: This method is used to decode percent-encoded characters within a given query string.

The `querystring` module is focused solely on manipulating URL query strings, so it requires the query string to have already been isolated from an incoming URL as part of a request. This means that some pre-processing of the URL is necessary before being able to use the module.

Additionally, it is worth noting that in the latest versions of Node (v16.x) the `querystring` module has become a legacy feature, with its core functionality having been absorbed into the `url` module via the `URLSearchParams` API. However, the features in the `querystring` module are still handy when using the long-term support versions of Node.js (v14.x).

The Querystring Module

Today is like any other normal day&mdash;you visit your favorite website to check out some new content or accomplish a task. The information appears on your page instantly, as if by magic. But have you ever wondered where that data came from and how it got there?  *How* did the website know what data to load for you? *Who* did it ask for that data? Or, more importantly, *how* did it ask for that data? These are all questions that slip through the cracks when we browse websites, but looking under the hood reveals a complex messaging system that is extremely interesting. This system, in part, is known as [*HTTP*](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol).

HTTP, short for Hypertext Transfer Protocol, is a request-response protocol that serves as the foundation of data exchange and communication within the client-server computing model. What this means in simpler terms is that HTTP helps facilitate the exchange of information between a client (i.e. website, mobile app, etc.) and a server.

At a base level, the operation of HTTP can be explained quite simply in the following steps detailing the request-response paradigm between a client and a server:

1) The client submits an HTTP *request* message to the server.
2) The server receives the HTTP request, performs some functions on behalf of the client according to the request.
3) The server returns a *response* message to the client containing important information about the processing of the request.

These three steps serve as the basis of communication via HTTP, enabling us to build and use complex web-based systems that are commonplace on the Internet today.

Diagram of HTTP request from a client to server and HTTP response from a server to client.

Introduction to HTTP

HTTP requests/responses contain all of the information needed to communicate with other entities on the web efficiently, but how do these messages actually make it to their destinations? Just as a letter requires a carrier to arrive at its destination, so too does an HTTP request. The carrier, in this case, comes in the form of transport protocols.

Various transport protocols exist, but let's take a look at the common ones that HTTP leverages to move around the web.  

#### TCP

The most common transport protocol used in conjunction with HTTP is [TCP](https://developer.mozilla.org/en-US/docs/Glossary/TCP). TCP stands for *Transmission Control Protocol* and allows two hosts to connect and exchange data streams, guaranteeing the delivery of data packets in the same order as they were sent. This means that TCP ensures that packets are delivered reliably and free from errors, positioning itself as an incredibly stable way to move data from one location to another.

#### UDP

[UDP](https://developer.mozilla.org/en-US/docs/Glossary/UDP), or *User Datagram Protocol*, is a less commonly used transport protocol. It operates using a connectionless communication model, requiring no "handshaking," which can potentially lead to unreliability in the delivery of messages. As such, UDP has no mechanism by which to guarantee delivery or ordering of messages. While these are certainly drawbacks for some types of applications, other applications that want to prioritize transmission speed and efficiency over security and reliability may leverage UDP.

While these transport protocols are great for moving your requests to their destination, they lack any meaningful security to protect the data while in transit. In order to remedy this issue, encryption protocols are commonly used.

#### TLS

[TLS](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/), also known as *Transport Layer Security*, is a widely adopted security protocol designed to facilitate secure data transmission via encryption. TLS evolved out of the encryption protocol known as [SSL](https://www.cloudflare.com/learning/ssl/what-is-ssl/) (Secure Sockets Layer), which has since been deprecated in favor of TLS. While these two protocols are different, the terms are sometimes used interchangeably. Using TLS with HTTP will allow you to use `HTTPS` (*Hypertext Transfer Protocol Secure*), which helps denote the presence of the extra security.

In conjunction with the different transport protocols mentioned above, there also exist different versions of HTTP. These distinct versions at a baseline operate similarly in that they carry information between entities and maintain important distinctions.

#### HTTP/1.1

[HTTP/1.1](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) was one of the first versions of the HTTP protocol to be designed and implemented. It operates by sending messages in the form of text. HTTP/1.1 is commonly used over TCP and is the slowest of the HTTP versions regarding data transmission.

#### HTTP/2

[HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) is a major revision of HTTP/1.1, developed with the intent to try and reduce web page load latency. However, the most significant departure from HTTP/1.1 is the encapsulation of all messages in binary format rather than plain text. This allows HTTP/2 to apply different techniques for data transmission, including sending smaller packets of data for greater flexibility of data transfer. This also allows a single connection to be made between two communicating entities rather than multiple as required by HTTP/1.1. Similar to HTTP/1.1, HTTP/2 also leverages TCP for transport.

#### HTTP/3

[HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) is the third major version of HTTP. While there are quite a few complex technological differences between HTTP/3 and the previous versions, one of the most important is how the protocol deals with lost packets. HTTP/3 also differs through its use of transport protocol, leveraging a transport protocol called [QUIC](https://en.wikipedia.org/wiki/QUIC), which applies specific controls over UDP. HTTP/3 is currently an [Internet Draft](https://en.wikipedia.org/wiki/Internet_Draft).

No matter which of these versions of HTTP are used over which transport protocol, the outcome is the same&mdash;the transmission of information in the form of a request and the reply to that request in the form of a response.

Diagram comparing data flow in UDP versus TCP.

The Movement of HTTP

HTTP is an extremely powerful tool that serves as one of the communication foundations of the modern web. It allows for communication between two entities over common transport protocols. By leveraging this robust communication ability, HTTP can be used to develop complex application architectures over networks, allowing servers to communicate with other servers, databases, and much more. Combining this with Node.js core modules such as `http`, `url`, and `querystring`, it has never been easier to build a complex application on the web.

Review

HTTP servers have to break down requests into their constituent parts to effectively process them and provide adequate responses. In that same vein, designing an [API](https://en.wikipedia.org/wiki/API) (Application Programming Interface) with endpoints intended to process specific requests in certain ways requires an understanding of the semantics of these requests, which are ultimately embodied within a [URL](https://en.wikipedia.org/wiki/URL) (Uniform Resource Locator).

A URL can provide a great deal of information about a request and how it is expected to behave. The image below provides a breakdown of the different parts of a URL and their meanings. A URL is made up of the following parts:

![Anatomy of a URL](https://static-assets.codecademy.com/Courses/Learn-Node/http/url-dark.png)

1) **Protocol**: The protocol of the URL denotes what protocol is being used for this particular resource. For instance, a URL could have a protocol of HTTP or HTTPS.

2) **Domain**: The domain of the URL is a unique reference that identifies a website on the Internet.

3) **Path**: The path refers to a file or directory on the web server. Paths oftentimes contain path parameters that APIs can process as a way to provide additional data when processing. For instance, to request a resource for a user with ID number `15`, we can add the user's ID to the URL like this: `/users/15`.

4) **Query**: The query is commonly found on pages that contain dynamic content. Queries are prefixed by a `?` and appear at the end of a URL. Queries can be comprised of multiple key/value pairs, separated by a `&`, with each key being assigned its corresponding value using a `=`. Queries are often used in conjunction with `GET` requests to pass filter parameters in order to provide specificity for the requested resource. For instance, to request all users that are active members, we could append a key/value pair of `active=true` to the end of our URL like this: `/users?active=true`.