Skip to content

Commit 5b8f250

Browse files
Sheikh-HSheikh-H
committed
new post
1 parent 8713532 commit 5b8f250

1 file changed

Lines changed: 165 additions & 0 deletions

File tree

‎_posts/30DaysOfPython/2026-01-17-python-day28.md‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
---
2+
layout: post
3+
title: APIs (Application Programming Interfaces) – Understanding HTTP and CRUD Operations
4+
description: >-
5+
In this learning journal, I explore how APIs work, how HTTP requests and responses are structured, and how these concepts connect to real-world applications. From understanding headers and status codes to filtering data and mapping CRUD operations, I reflect on my journey learning how web systems communicate behind the scenes.
6+
author: Sheikh Hussain
7+
date: 2025-12-17 17:00:00 +0000
8+
categories: [Python Course, 30 Days of Python - Asabeneh]
9+
tags: [python, programming, course, 30days, day28, API, HTTP, Networking]
10+
pin: false
11+
math: false
12+
mermaid: false
13+
render_with_liquid: false
14+
media_subpath: /assets/img/posts/
15+
---
16+
17+
## What Is an API?
18+
19+
You can think of an <abbr title = "Application Programming Interface">API</abbr> as being a method that allows two separate systems to communicate with each other. The API is what allows the system/software to **automatically** send and recieve requests.
20+
21+
A more detailed example would be to think of services like weather applications, delivery updates, or mobile application requests. In all these examples, the application doesn't store data and instead uses another system for data handling.
22+
23+
# Introduction to HTTP
24+
25+
To deepen my understanding of APIs, I took to remeniscing about what I had learnt on <abbr title = "Hyper-Text Transfer Protocol">HTTP</abbr> and how a _request_ is made over the web and received. HTTP defines how information is relayed between a client (system, application, or browser) and a server.
26+
27+
Whenever we visit a website or search for something online or in a website, our browsers are sending a **HTTP request** with the information we want and the server is what replies with a **HTTP response** containing all the information.
28+
29+
# HTTP Requests
30+
31+
This is what a basic HTTP request looks like:
32+
33+
```http
34+
GET /students HTTP/1.1
35+
Host: example.com
36+
Accept: application/json
37+
...
38+
```
39+
40+
From this, I can identify:
41+
42+
**GET** - the HTTP Method (requesting data)
43+
**/students** - the resource being requested
44+
**HTTP/1.1** - the HTTP protocol version
45+
**Headers** - extra information about the request
46+
47+
This request is asking the server to return a list of students in JSON format.
48+
49+
## What are HTTP Methods
50+
51+
**HTTP Methods** will seem very similar to database CRUD (Create, Read, Update, Delete) operations, and that's with intent. Each CRUD operation works with an HTTP method to ensure the action is performed correctly.
52+
53+
Here is a mental map that I can use to grasp the concept:
54+
55+
GET - Read data (Read)
56+
POST - Create new data (Create)
57+
PUT - Replace existing data (Update)
58+
PATCH - Update part of existing data (Update)
59+
DELETE - Remove data (Delete)
60+
61+
## HTTP Responses
62+
63+
When a server sends a response, it typically includes:
64+
65+
1. A status code (200, 404, etc.)
66+
2. Headers
67+
3. A response body (the actual data)
68+
69+
Here's an example of an HTTP response:
70+
71+
```http
72+
HTTP/1.1 200 OK
73+
Content-Type: application/json
74+
75+
[
76+
{"name": "Sheikh Hussain", "grade": "C"},
77+
{"name": "Alif Roshan", "grade": "B"}
78+
]
79+
```
80+
81+
The key information presented here is the `HTTP/1.1 200 OK` part, as this includes the status code. I've already discussed what all the status codes are in another post, but `200 OK` means the request was successful.
82+
83+
## Understanding HTTP Headers
84+
85+
**HTTP headers** are metadata on the request or response made. Think of them as additional bits of information that explain _how_ the data should be handled.
86+
87+
Here are some:
88+
89+
Host - which server is being contacted
90+
Accept - what type of data the client expects
91+
Content-Type - what type of data is being sent back
92+
93+
There are many more that I could include, but this is enough.
94+
95+
## A More Granular Example
96+
97+
The earlier example of an HTTP request was made for a whole collection/table of data. What if we wanted specific information from the server?
98+
99+
Think about the time when we use search filters on sites and how they produce a list of results. For that, the HTTP request is made to be more detailed.
100+
101+
_Get all the students' names and age fields who got a grade C_:
102+
103+
```http
104+
GET /students?grade=C&fields=name,age HTTP/1.1
105+
```
106+
107+
## A Realistic HTTP Request Example
108+
109+
To make sure I understood all about HTTP requests and responses, I wanted to include an actual example that was placed in the course contents. This should give a better idea of what an actual request should look like.
110+
111+
```http
112+
GET / HTTP/1.1
113+
Host: thirtydaysofpython-v1-final.herokuapp.com
114+
Connection: keep-alive
115+
Pragma: no-cache
116+
Cache-Control: no-cache
117+
Upgrade-Insecure-Requests: 1
118+
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36
119+
Sec-Fetch-User: ?1
120+
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
121+
Sec-Fetch-Site: same-origin
122+
Sec-Fetch-Mode: navigate
123+
Referer: https://thirtydaysofpython-v1-final.herokuapp.com/post
124+
Accept-Encoding: gzip, deflate, br
125+
Accept-Language: en-GB,en;q=0.9,fi-FI;q=0.8,fi;q=0.7,en-CA;q=0.6,en-US;q=0.5,fr;q=0.4
126+
```
127+
128+
I haven't explored all the header metadata information just yet, but most of them do seem self-explanatory.
129+
130+
## What Happens Before a Response is Sent?
131+
132+
I wanted to include this topic as being or forming part of this module in the course, as this information helps to comprehend the information better. Before an HTTP request is made from the client to the server, a connection must be created.
133+
134+
This is done using what is known as a **3-way TCP Handshake**. Before I explain a TCP handshake, I would also have to also go over what TCP/IP is.
135+
136+
In computer networking, we come across the term <abbr title="Transmission Control Protocol / Internet Protocol">TCP/IP</abbr>, which illustrates what the different layers within a network are. We also learn about <abbr title = "Open Systems Interconnectivity">OSI</abbr> model, which is often described as being an extension to the TCP/IP model.
137+
138+
### TCP/IP and OSI Model
139+
140+
Before any communication is sent over a network, there are protocols set in place to ensure all information is sent and received _reliably_. It's important to understand this information as it helps later.
141+
142+
Each layer performs a set of instructions on the data or network and then sends out the data as packets.
143+
144+
Here is an image that describes both models, if you'd like to learn about the OSI and TCP/IP models, I would recommend visiting the web. I want to stay on topic for my posts.
145+
146+
![TCP/IP Model - Geeks For Geeks](https://media.geeksforgeeks.org/wp-content/uploads/20251215161450630019/osi-to-tcp.webp)
147+
148+
### 3-Way TCP Handshake
149+
150+
At a high-level, during the TCP/IP or OSI protocols a _sub-request_ is sent to the server to ensure that the server is okay to receive a request and send a response. This is often where you would come across _server timed out_ errors.
151+
152+
All that happens is, the client sends a synchronise request, receives a synchronise and acknowledge response, and sends back an acknowledge is sent from the client back to the server.
153+
154+
This diagram should help with visualising the concept:
155+
![3-Way TCP Handshake - Geeks for Geeks](https://media.geeksforgeeks.org/wp-content/uploads/handshake-1.png)
156+
157+
This is a topic for another time, but it can get very indepth and I would suggest consuming as much content as possible on this to get the complete picture.
158+
159+
## Summary
160+
161+
With all that discussed, that sums up today's work. I know it seems less practical and more theoretical for a change; however, it's good information that we can think on when brainstorming on how your everyday browser and applications work.
162+
163+
This insight alone promotes creative thinking for me as it starts to highlight how data is being sent and received, and what types of data are available. I should keep in mind here that while I have been discussing the majority of my examples around database queries, we use the same methods to send and receive images, videos, documents, and many other file formats.
164+
165+
To include some more interesting information, when we play video games over an online server or have a video call with someone. We don't use the 3-way handshake, and instead we use a <abbr title = "User Datagram Protocol">UDP</abbr>, which just send the information in a stream-like form.

0 commit comments

Comments
 (0)