HTTP, REST APIs, Status Codes & Ports — Beginner's Guide

HTTP Methods, Status Codes, Ports & REST APIs

A complete beginner-friendly guide

0. What Is HTTP, Really?

HTTP stands for HyperText Transfer Protocol. It is simply an agreed-upon set of rules that a client (like your browser or
mobile app) and a server (a computer that stores data or runs a service) use to talk to each other over the internet. One side
sends a 'request', the other side sends back a 'response'. Every time you open a webpage, tap a button in an app, or an app
fetches your bank balance, an HTTP request/response is happening behind the scenes.
Beginner analogy: Think of a restaurant. You (the client) tell the waiter (HTTP) what you want — 'bring me the menu' or
'I'll have the pasta.' The waiter carries your request to the kitchen (the server), and the kitchen prepares a response (your
food, or a message like 'sorry, we're out of pasta') which the waiter brings back to you. HTTP is just the waiter — the
language and steps used to carry requests and responses back and forth.

The Request/Response Cycle

CLIENT SERVER
(Browser/App) (Web/API server)
| |
|------ HTTP Request ----------->| e.g. GET /api/users/5
| | Server looks up user 5
|<----- HTTP Response -----------| e.g. 200 OK + user data (JSON)
| |

This single round trip — one request, one response — is the basic unit of almost everything that happens on the web.

Anatomy of a Request
A raw HTTP request has three parts: a start line (method + path + HTTP version), headers (metadata about the request), and
an optional body (data being sent, e.g. for creating something).

POST /api/users HTTP/1.1

Host: [Link]
Content-Type: application/json
Authorization: Bearer <token>

{
"name": "Asha",
"email": "asha@[Link]"
}

Anatomy of a Response
A response mirrors this: a status line (HTTP version + status code + short text), headers, and a body containing the requested
data or an error message.

HTTP/1.1 201 Created

Content-Type: application/json

{
"id": 42,
"name": "Asha",
"email": "asha@[Link]"
}

Durbhasi Gurukulam Page 1 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide

1. HTTP Methods (Verbs) — In Depth

HTTP methods (also called 'verbs') tell the server WHAT ACTION the client wants to perform on a resource. A 'resource' is
just a piece of data with an address (URL), like a specific user, order, or blog post. REST APIs map these verbs directly onto
the four basic database operations, often remembered as CRUD: Create, Read, Update, Delete.

Method Safe/ Purpose (why it's used) Typical Use

Idempotent

GET Safe, Retrieve a representation of a resource without changing server Fetch a user,
Idempotent state. list orders

POST Not safe, Not Create a new resource or trigger a process; server usually Create a new
idempotent assigns the new ID. order

PUT Not safe, Replace a resource entirely at a known URI. Replace a user
Idempotent record

PATCH Not safe, Not Apply a partial update to a resource. Update one
always field
idempotent

DELETE Not safe, Remove a resource. Delete an order

Idempotent

HEAD Safe, Same as GET but headers only, no body. Check if

Idempotent resource exists

OPTIONS Safe, Discover allowed methods / CORS rules. CORS pre-

Idempotent flight
Below, each method is explained individually so a complete beginner can see exactly why it exists and when to reach for it.

GET — Read data

GET asks the server to send back a copy of a resource. It should never change anything on the server — it only reads.
Beginner analogy: Like looking through a shop window. You can look as many times as you like — nothing in the shop
changes just because you looked.

GET /api/books/12 HTTP/1.1

Host: [Link]

Why GET specifically: it is 'safe' (causes no side effects) and 'idempotent' (calling it 1 time or 100 times gives the same
result), so browsers and networks are allowed to cache GET responses to make things faster.

POST — Create data / trigger an action

POST asks the server to create a brand-new resource, or to trigger some process, using the data sent in the request body. The
client usually doesn't know the final address (URL/ID) of the new item beforehand — the server decides that and returns it.
Beginner analogy: Like dropping a new form into a suggestion box. Every time you drop in a form, the box adds a new
item — drop the same form in twice and you get two separate entries, not one.

POST /api/books HTTP/1.1

Content-Type: application/json

{ "title": "Atomic Habits", "author": "James Clear" }

Why POST specifically: it is neither safe nor idempotent — calling it again with the same data is expected to create another
new resource, which is exactly why it's used only for creation/actions and not for simple reads.

Durbhasi Gurukulam Page 2 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide
PUT — Replace data completely
PUT asks the server to replace an existing resource entirely with the new data provided. The client must send the FULL
object, including fields that aren't changing.
Beginner analogy: Like swapping out an entire filled-in form with a brand new filled-in form — whatever was on the old
form is gone, replaced completely by the new one.

PUT /api/books/12 HTTP/1.1

Content-Type: application/json

{ "title": "Atomic Habits", "author": "James Clear", "year": 2018 }

Why PUT specifically: it is idempotent — sending the exact same PUT request 1 time or 10 times leaves the resource in the
same final state, which makes it predictable and safe to retry if a request fails due to a network glitch.

PATCH — Update data partially

PATCH asks the server to change only the specific fields provided, leaving everything else untouched.
Beginner analogy: Like using correction fluid on just one line of a form instead of filling out the whole form again.

PATCH /api/books/12 HTTP/1.1

Content-Type: application/json

{ "year": 2019 }

Why PATCH specifically: it saves bandwidth and avoids accidentally overwriting fields the client doesn't know about, which
is a real risk with PUT if the client's copy of the data is outdated.

DELETE — Remove data

DELETE asks the server to remove the specified resource so it no longer exists.
Beginner analogy: Like tearing up a form and throwing it in the bin — it's gone.

DELETE /api/books/12 HTTP/1.1

Why DELETE specifically: it is idempotent — deleting the same item twice still ends with 'it doesn't exist', so repeating the
call after a failed attempt is safe.

HEAD — Check without downloading

HEAD works exactly like GET, but the server sends back only the headers, no body. It's used to check things like whether a
resource exists, its size, or when it was last changed, without downloading the whole thing.
Beginner analogy: Like asking 'is the shop open?' without walking inside and looking at every shelf.

OPTIONS — Discover what's allowed

OPTIONS asks the server which HTTP methods and rules are allowed for a resource. It is mostly used automatically by web
browsers as a 'pre-flight' check before making cross-origin requests (CORS), to confirm the real request will be permitted.

Idempotency and Safety, Explained Simply

These two words come up constantly and are worth understanding properly:
● Safe = doesn't change anything on the server. Only GET, HEAD, and OPTIONS are safe.
● Idempotent = calling it once has the same end result as calling it many times. GET, PUT, DELETE, HEAD,
OPTIONS are idempotent; POST is not; PATCH sometimes is, sometimes isn't, depending on how it's
implemented.

Durbhasi Gurukulam Page 3 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide
Beginner analogy: Flipping a light switch to 'ON' is idempotent — no matter how many times you set it to ON, the end
state is the same: the light is on. But pressing a doorbell is not idempotent — pressing it 5 times rings the bell 5 times,
causing 5 separate effects, similar to how POST can create 5 separate resources if called 5 times.

2. HTTP Status Codes — In Depth

Every HTTP response includes a 3-digit status code that tells the client, in a standard way, what happened to its request. The
first digit tells you the category at a glance, so even without memorizing every code, you can understand roughly what
occurred.
● 1xx (Informational) — request received, still processing.
● 2xx (Success) — everything worked as expected.
● 3xx (Redirection) — you need to look somewhere else to complete this.
● 4xx (Client Error) — the client (you) did something wrong in the request.
● 5xx (Server Error) — the server broke while trying to handle a valid request.
Beginner analogy: Think of ordering food by app. 2xx is 'order confirmed and delivered'. 3xx is 'that restaurant moved,
here's the new one'. 4xx is 'your order form was incomplete or you're not logged in' (your fault, fixable by you). 5xx is 'the
restaurant's kitchen caught fire' (their fault, nothing you did wrong).

1xx & 2xx — Informational and Success

Code Name Meaning Beginner example

100 Continue Client should continue sending the Uploading a large file in parts.
request body.

101 Switching Protocols Server agrees to switch protocols (e.g. Chat app upgrading HTTP to WebSocket.
to WebSocket).

200 OK Request succeeded; body has the GET /users/5 returns the user's JSON.
result.

201 Created New resource was created POST /users returns the newly created
successfully. user.

202 Accepted Request accepted, processing not Video upload queued for conversion.
finished yet.

204 No Content Success, but nothing to send back. DELETE /users/5 succeeds with empty
body.

3xx — Redirection
Code Name Meaning Beginner example

301 Moved Permanently Resource now lives at a new URL Old blog URL permanently redirects to
forever. new domain.

302 Found Resource is temporarily at a different Redirect to a maintenance page for a

URL. while.

304 Not Modified Cached copy is still valid, no need to Browser reuses cached CSS file.
re-download.

Durbhasi Gurukulam Page 4 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide
4xx — Client Errors
Code Name Meaning Beginner example

400 Bad Request Request was malformed or missing Sending text where a number was
required data. expected.

401 Unauthorized You must log in / provide valid Accessing an account API without a
credentials. token.

403 Forbidden You are identified, but not allowed to A regular user trying to access admin
do this. data.

404 Not Found The resource does not exist at this GET /users/9999 when no such user
URL. exists.

405 Method Not This HTTP method isn't supported Sending DELETE to a read-only
Allowed here. endpoint.

409 Conflict Request conflicts with the current Trying to create a username that already
state. exists.

422 Unprocessable Data format is fine, but values fail Email field doesn't contain a valid email.
Entity validation.

429 Too Many Requests You have sent too many requests too Hitting an API rate limit of 100
fast. calls/minute.

5xx — Server Errors

Code Name Meaning Beginner example

500 Internal Server Error Something broke inside the server's An unhandled bug/exception in the
own code. backend.

502 Bad Gateway A server acting as a proxy got an Load balancer's backend server crashed.
invalid reply upstream.

503 Service Unavailable Server is overloaded or down for Site down briefly during a deployment.
maintenance.

504 Gateway Timeout Upstream server took too long to Database query took too long, request
respond. timed out.

3. Common Network Ports — In Depth

A computer can run many different services at once (a website, a database, an email server), all sharing one IP address. A
'port' is a number that tells incoming traffic which specific service on that computer it's meant for — like a door number
within one large building.
Beginner analogy: An IP address is like the street address of an apartment building. The port number is like the specific
apartment/door number inside that building — mail (data) for apartment 443 (HTTPS) goes to a completely different place
than mail for apartment 22 (SSH), even though it's the same building (same server).

Port Service TCP/UDP What it's for

20/21 FTP TCP File Transfer Protocol — 20 carries the actual file data, 21
carries commands like login and list files.

22 SSH TCP Secure Shell — encrypted remote terminal access to a server,

also used for secure file copy (SCP/SFTP) and Git over SSH.

Durbhasi Gurukulam Page 5 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide

Port Service TCP/UDP What it's for

23 Telnet TCP Old, unencrypted remote login. Rarely used today because
anyone snooping the network can read the traffic in plain text.

25 SMTP TCP Simple Mail Transfer Protocol — used by mail servers to send
email to each other.

53 DNS TCP/UDP Domain Name System — translates a name like [Link]

into an IP address like [Link].

80 HTTP TCP Standard, unencrypted web traffic. What your browser uses by
default before HTTPS became the norm.

110 POP3 TCP Post Office Protocol — downloads email from a server to one
device, usually removing it from the server.

143 IMAP TCP Retrieves email but keeps it synced on the server, so it shows
the same across all your devices.

443 HTTPS TCP Encrypted web traffic using TLS/SSL. This is the standard port
for production REST APIs and websites today.

3306 MySQL TCP Default port a MySQL database listens on for connections from
an application.

5432 PostgreSQL TCP Default port a PostgreSQL database listens on.

6379 Redis TCP Default port for Redis, an in-memory data store often used for
caching.

8080 HTTP (alt) TCP Common alternate port for web servers, local development, and
proxies when port 80 is already in use or restricted.

27017 MongoDB TCP Default port for MongoDB, a popular NoSQL document
database.
TCP (Transmission Control Protocol) guarantees reliable, ordered delivery of data and is used by most services above,
including HTTP/HTTPS. UDP (User Datagram Protocol) is faster but doesn't guarantee delivery or order, which is why DNS
can use either depending on the situation, and why things like video calls or games often use UDP.

4. REST APIs — Putting It All Together

REST (Representational State Transfer) is simply a style of designing APIs using standard HTTP the way it was intended:
resources as nouns in the URL, and HTTP methods as the verbs that act on them. A REST API doesn't invent new rules — it
reuses everything above consistently.

Core REST Principles for Beginners

● Resources are nouns: /api/books, /api/books/12 — never verbs like /api/getBook.
● HTTP methods are the verbs: GET reads, POST creates, PUT/PATCH update, DELETE removes.
● Statelessness: each request must carry everything the server needs (like an auth token) — the server does not
remember you between requests.
● Uniform interface: the same method always means the same thing everywhere in the API, so once you learn the
pattern, you can predict how any endpoint behaves.
● Status codes communicate outcome consistently, so client code can react the same way (e.g. always retry on 503,
always show a login screen on 401).

Durbhasi Gurukulam Page 6 of 7

 HTTP, REST APIs, Status Codes & Ports — Beginner's Guide
Full Example: Managing a 'Book' Resource
Here is the same resource taken through its entire lifecycle using every method and matching status code, exactly as a real
REST API would behave:

1) CREATE
POST /api/books body: {title, author}
-> 201 Created body: {id:12, title, author}

2) READ (one item)

GET /api/books/12
-> 200 OK body: {id:12, title, author}

3) READ (list)
GET /api/books
-> 200 OK body: [ {id:12,...}, {id:13,...} ]

4) FULL UPDATE
PUT /api/books/12 body: {title, author, year}
-> 200 OK body: updated object

5) PARTIAL UPDATE
PATCH /api/books/12 body: {year: 2019}
-> 200 OK body: updated object

6) DELETE
DELETE /api/books/12
-> 204 No Content

7) NOT FOUND (after deletion)

GET /api/books/12
-> 404 Not Found

Notice how the URL (/api/books/12) barely changes — only the HTTP method changes to express a different action, and the
status code tells the client exactly what happened each time. This consistency is the entire point of REST, and is why
learning HTTP methods, status codes, and ports properly makes any REST API easy to understand, no matter which
company built it.

5. One-Page Cheat Sheet

● GET = read (safe, idempotent) | POST = create (not safe, not idempotent)
● PUT = replace fully (idempotent) | PATCH = update partially
● DELETE = remove (idempotent) | HEAD = headers only | OPTIONS = discover allowed methods
● 2xx = success | 3xx = redirect | 4xx = your mistake | 5xx = their mistake
● 80 = HTTP | 443 = HTTPS | 22 = SSH | 53 = DNS | 8080 = HTTP alt/dev
● REST = resources as nouns in URLs + HTTP methods as verbs + consistent status codes + statelessness

Durbhasi Gurukulam Page 7 of 7