We see HTTP everywhere on the web. It’s considered one of its backbones. Think of it as the “language” that allows browsers, servers and websites to talk to one another. HTTP is a protocol that defines a structured way to request and exchange information. With an HTTP server, you can provide access to data, tools and services, allowing a client to request information or trigger actions.

Think of HTTP like ordering at a restaurant. You don’t walk into the kitchen and ask the chef for your meal yourself. You give your meal order to the server. The server passes along your order to the right people and then, a short time later, you have a finished meal. If you need something else, like salt, you again speak to the server rather than finding salt yourself. HTTP works similarly. Your browser sends a request to the web server, and the web server figures out where the right information is and delivers it back to your browser.

In this analogy, the human server represents the HTTP server. It takes in the browser’s request for information, identifies where the information is and returns it to the browser.

An HTTP server is a service that:

• Exposes resources (like webpages, APIs and files)
• Provides capabilities (actions a client can request, like submitting a form or fetching data)
• Communicates using HTTP (the protocol your browser or client uses to send requests and receive responses)

At the heart of HTTP are requests and responses. These are the messages your browser and a server send back and forth to share information. Requests and responses allow HTTP to flow like a conversation between your browser and a server. Your browser sends a request asking for something (a webpage, an image or more TikTok videos). The server receives the request, figures out how to get the information and sends a response back.

One last thing before we build our simple HTTP server. We’ve all seen a 404 error, usually with some sad-looking character beside it. 404 is a status code letting the browser know that the endpoint or path it requested isn’t available. The endpoint or path is the address that tells the server what resource to return. For basic web browsing, this would be the web address. There are other status codes, too, though they aren’t always shown. For example, 200 is the status code the server returns when everything is working correctly.

There’s more to learn as this is a deep topic, but at this point, we’re ready to start building.

Prerequisites

• Python 3.0+
• Basic terminal knowledge (you’ll be running commands in the terminal)
• Nano or another text editor (we’ll use nano, but you can use VS Code, Vim, etc.)
• pip (Python’s package manager, usually included with Python 3)
• Basic understanding of HTTP (what a request and response are)

Building Our HTTP Server Using Python

We’re going to build an HTTP server that serves weather data. Our server will mimic how you might structure an HTTP server around a real API. Later, you could swap the fake dataset with actual API calls.

Create the Fake Data

We’ll use Python for the fake weather data because Python dictionaries are easy to work with and can be converted to JSON to send to clients. This makes our app simpler and faster to test.

The Python dictionary below will act like our “database” or “API backend.” If you were working with a real API, you could replace it with live API calls.

In your project folder, create a new file by typing nano fake_weather_data.py in the terminal. If you’re using another IDE, just skip the nano.

Build the HTTP Server

Now we’re ready to build the server file. In the terminal, type nano weather_server.py (or skip the nano if using another IDE).

The weather_server.py file is where we define what we’re looking for (available cities) and the details (weather lookup) using a lightweight HTTP server. It acts as a simulated external data source that scripts or other clients can query just like a live weather API.

The server reads from fake_weather_data.py and handles basic error checking. If a client requests a path that doesn’t exist, it responds with a 404. If a client asks for a city not in the data set, it returns a clear JSON error message. This makes it easy to test clients or simulate real-world workflows without needing access to an actual API.

The server runs continuously on 127.0.0.1:5000. Clients can query it at any time. It provides resources and procedures, handles requests and returns structured JSON responses, making it easy to integrate into larger projects.

Our server uses urllib, a built-in Python module that provides tools for working with URLs. Its main use is to send HTTP requests and handle responses, making it a way for Python programs to “talk to” web servers or APIs.

Create Client To Test HTTP Server

Let’s create our client file. In the terminal, type nano weather_client.py.

The weather_client.py file acts as a consumer of the simulated weather server, sending requests to query its data. The client connects to the server running at 127.0.0.1:5000 and demonstrates how clients can interact with available data.

First, it queries the endpoint /weather/cities to get a list of all available cities. Then, it calls the /get_weather endpoint for a specific city (Tokyo in this example) and prints the structured JSON response.

This client demonstrates how an external program can consume a data source, parse the results and act on the returned information. It handles responses simply by printing the data to the console, but could easily be extended to integrate into larger workflows or dashboards.

Run the Server and Client

In the same terminal, run the command python weather_server.py. This will start the server.

Now open a new terminal, make sure to point it to the same project folder, and type python weather_client.py. This will run the client. After you run the client, you should see the following return in your terminal:

And there you have it. You created your first server. You can use this as a guide now to build more complex, custom HTTP servers that better suit your working environment and needs.

TRENDING STORIES