Welcome to internet city

November 30, 2025

To get anything from the internet, you have to play by its rules:

Go to the right building. Enter the correct department. Reach the floor where the service runs. Walk into the specific room. Open the exact drawer. Speak the language the system understands. Carry a badge that proves you belong there.

Miss one step? The request fails.

Use the wrong verb? Rejected.

Forget your credentials? Kicked out before you reach the elevator.

Here’s how everything connects

The City          →  The Internet (global network)

Buildings         →  Servers (192.168.1.1, 104.26.13.45)

Departments       →  Ports (:80, :443, :8000)

Floors            →  Applications (Nginx, Node.js, FastAPI)

Rooms             →  Routes (/users, /orders, /products)

Cabinets          →  Collections (all users, all orders)

Drawers           →  Resources (/users/42, /orders/101)

Documents         →  JSON/XML response data

Language spoken   →  HTTP Verbs (GET, POST, PUT, DELETE)

Badge             →  Auth tokens (JWT, API keys)

Signs on walls    →  Status codes (200, 404, 500)

So when you write:

fetch('https://api.example.com:443/users/42', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer your-token-here'
  }
})

You’re literally saying: “Go to example.com’s building (server), enter department 443 (HTTPS port), walk into the users room (route), open drawer 42 (specific user), and show me the documents inside. Here’s my badge for entry.”

https://api.example.com:443/users/42

where :

https → Protocol

api.example.com → Domain (Building)

443 → Port (Department)

/users → Path (Room)

/42 → Resource (Drawer)

Now let’s break down each piece.

The City = The Internet

Picture a massive city with buildings, roads, signs, and transport systems everywhere.

That’s the internet.

Data travels like vehicles on roads, following traffic laws (TCP/UDP protocols).

Everything moves on top of this shared infrastructure that connects us all.

The Buildings = Servers

A server is like a building placed somewhere inside this giant city.

When you type a domain like google.com, you are basically saying “take me to the Google building.”

But you do not know the exact street address of that building. So DNS steps in.

DNS is a directory service that maps names to addresses.

It tells you the building’s actual street address, which is the IP address.

Every building must have a unique address.

If two buildings share the same number, deliveries and visitors would get mixed up.

The same problem happens if two servers claim the same IP address. Packets get lost and communication breaks.

A server can host many teams or services inside it.

Just like a real building may hold multiple companies on different floors.

The Departments = Ports

When you enter a building, you do not go straight to every room.

You visit a department first.

Departments inside buildings have extension numbers to help route people correctly.

Ports serve the same purpose on a server.

Port 80 is the department for plain HTTP traffic.

Port 443 is for HTTPS.

Port 22 is for secure shell access.

Your own backend can choose a department like 5000 or 8000.

If you contact the wrong port, nobody answers your request.

The building does not know which team you want to speak to.

Ports create the first level of order inside the server.

Asking the wrong port the wrong thing gives you errors,

Just the same way asking for payroll details from the Marketing department gets you errors

The Floor = The Application

Once you reach the correct department, someone takes you to the correct floor.

A floor represents the actual program that is running on that port.

For example:
Port 443 might lead to an Nginx web server on Floor 12.

Port 3000 might lead to a Node application on Floor 5.

Port 8000 might lead to a FastAPI backend on Floor 3.

The department (port) is like the front desk.

The floor (application) is where the real work happens.

The Rooms = Router

Each floor has many different rooms, each with a specific purpose.
In an API, these rooms are the routes.

The Users room handles anything related to user information.
The Orders room deals with new orders or order history.
The Products room deals with product details.

/users
/orders
/products

When you visit /users, you walk into the Users room.

When you visit /products, you walk into the Products room.

You can ask about users only in the users room and not in the product room

Rooms help keep the application organized so you never mix up responsibilities..

The Cabinets = Collections

Every room has storage units.

In the Users room, there is a cabinet that holds information about all users.

The route /users refers to that cabinet as a whole.

It is the entire collection of user data.

The same idea applies to /orders, /tasks, or any collection endpoint.

It means “show me the entire storage for this type of thing.”

The Drawers = Individual Resources

Each item in your collection is a drawer in the cabinet. When you request:

/users/42

You’re saying:

Building: this server
Department: this port
Room: users
Cabinet: all users
Drawer #42: this specific user

You’ve put your hand on exactly the drawer you need.

You are not asking for the entire cabinet.

You are asking for one exact unit inside it.

The system now knows exactly where your request is pointing.

The Documents = Resource Representation

When you open a drawer, you see documents inside.

These represent the data that the server returns to you.

The JSON response is not the actual person, order, or product.

It is a snapshot that describes the resource.

{
  "id": 42,
  "name": "Atharv",
  "email": "ath@example.com"
}

This isn’t the actual user. It’s a representation of that user that the server gives you. That’s why it’s called REST (Representational State Transfer). You’re transferring representations of resources, not the resources themselves.

The Language = HTTP Verbs

Inside a building, you cannot just do anything you want.

You tell the staff what you want to do using a normal, clear phrase.

HTTP verbs work the same way.

GET means “just show me what is in the drawer.”

POST means “create a new drawer and place something inside it.”

PUT means “replace the contents of the drawer with something new.”

PATCH means “make a small update to what is already inside.”

DELETE means “remove this drawer completely.”

If the staff hears the wrong instruction, they will kick you out.

The Badge = Authentication

Every building has security.

They check your badge before letting you enter deeper areas.

This badge can be a token, API key, or session cookie.

The Authorization header is you showing your badge to the guards.

If you do not have permission, you are stopped immediately.

You cannot even reach the elevator.

The Signs = Status Codes

Every department puts signs outside their rooms to show what happened with your request.

200 means “everything worked.”

201 means “something new was created.”

401 means “you did not show a badge.”

403 means “your badge does not allow you to enter this area.”

404 means “the drawer you want does not exist.”

409 means “there is a conflict, something is already there.”

500 means “the department had a breakdown while processing your request.”

These signs help developers understand problems quickly without guessing.

Putting It All Together

When you make a request like:

GET https://api.example.com:443/users/42

Here’s what actually happens:

Enter the city (internet)
Navigate to the building at that address (DNS translates the domain into the server’s IP, and you travel to that location)
Walk into department 443 (HTTPS port)
Enter the Users room (/users route)
Find the cabinet of all users (collection)
Pull out drawer 42 (specific resource)
Staff hands you the document inside (JSON response)
You used GET, so you’re just looking
They reply with 200 OK

This mental model scales beautifully. It works for everything from physical networking hardware all the way up to high-level REST API design. Once you internalize this metaphor, concepts like load balancing (multiple buildings handling the same address), microservices (specialized departments), API gateways (front desks that route you), and database connections (the filing system in the basement) all click into place naturally.

The best part? You’ll never have to re-learn these concepts. The city is always there in your mind, ready to help you debug, design, or explain backend systems to anyone.

Exploring common errors in Internet city

1. Wrong Building — Hitting the Wrong Domain / Environment (DNS / 404 / Resolution Fail)

Analogy: You’re looking for 123 Main Street, but that address doesn’t exist anywhere in this city.
What happened: The domain name is wrong, DNS can’t find it, or the server is offline.
Fix: Check the URL spelling. Try pinging the domain to confirm it resolves.

2. Wrong Department — Wrong Port or Protocol (400 / Connection Refused)

Analogy: You found the building, but all the doors are locked and nobody’s home.
What happened: The server is down, the port is closed, or a firewall is blocking your entry.
Fix: Verify the service is running and that you’re knocking on the right port.

3. No Badge — Missing or Invalid Credentials (401 Unauthorized)

Analogy: You showed up without your employee badge. Security won’t even let you into the lobby.
What happened: Missing or invalid authentication token/API key.
Fix: Add the correct Authorization header. Get a fresh token if needed.

4. Wrong Room Instruction — Wrong HTTP Verb (405 Method Not Allowed)

Analogy: You walked into a library and yelled, “DELETE ALL BOOKS!” and they immediately threw you out.
What happened: You used GET on a POST-only endpoint, or DELETE where only GET is allowed.
Fix: Check what HTTP methods the endpoint supports and use the right one.

5. Drawer Doesn’t Exist — Missing Resource (404 Not Found)

Analogy: You’re searching for “Room 742” but the building only has 600 rooms.
What happened: Wrong URL, deleted resource, or just a typo in the endpoint.
Fix: Double-check your spelling. Confirm the resource actually exists.

6. Badge Works, But Not for This Area — Permission Issue (403 Forbidden)

Analogy: You have a badge for the Marketing department, but you’re trying to walk into the CEO’s office.
What happened: You’re authenticated but not authorized for that specific resource.
Fix: Check your permissions or switch to an account that actually has access.

7. Form Filled Wrong — Invalid Request Body (400 Bad Request)

Analogy: You filled out a form with crayons, skipped half the fields, and wrote your name where the date should be.
What happened: You sent gibberish the server can’t parse.
Fix: Fix your request body — required fields, correct data types, proper formatting. Read the API docs.

8. Same Room, Wrong Map — Caching or CDN Issues (304 / Stale Data)

Analogy: You’re still carrying last month’s map, so you keep going to the company’s old building.
What happened: You’re seeing cached or outdated data.
Fix: Clear caches, adjust cache headers, or version your requests.

9. Two Clerks Changing the Same Drawer — Race Conditions (409 Conflict)

Analogy: You asked two different clerks to update the same drawer at the same time. They both did something, but now the drawer’s a mess.
What happened: Two operations clashed on the same resource.
Fix: Serialize updates, add locking, or use version checks.

10. Buzzing the Desk Too Often — Flooding the Server (429 Too Many Requests)

Analogy: You’re that annoying person buzzing the front desk every two seconds. They eventually ban you for a while.
What happened: You hit the rate limit.
Fix: Slow down. Add pauses or batching. Use fewer requests.

11. Floor Breakdown — Server Crash (500 Internal Server Error)

Analogy: The building’s power went out. Everyone is standing around confused.
What happened: Their server broke internally, not your fault.
Fix: Wait and retry later. Check their status page if they have one.

12. Receptionist Can’t Reach Inside — Upstream Failure (502 Bad Gateway)

Analogy: The receptionist tried calling accounting, but the internal phone lines are dead.
What happened: One of their backend services is down.
Fix: Nothing for you to fix directly. Add retry logic.

13. “Come Back Later” Sign — Service Overloaded (503 Service Unavailable)

Analogy: The building is at maximum capacity, and they’ve put a “come back later” sign on the door.
What happened: Server overloaded or in maintenance mode.
Fix: Wait and retry with exponential backoff.

14. Reception Waited Too Long — Slow Upstream (504 Gateway Timeout)

Analogy: The receptionist waited 30 seconds for accounting to answer, then gave up.
What happened: Their backend service took too long to respond.
Fix: Your request might be too heavy, or their servers are slow. Retry or simplify.

15. Address Not Found — DNS Resolution Failed (DNS Error)

Analogy: You looked for “123 Main Street,” but the city directory says no such place exists.
What happened: DNS failed to resolve the domain.
Fix: Verify the domain spelling and DNS configuration.

16. Building Locked — Connection Refused (Connection Error)

Analogy: You found the building, but every door is locked and dark.
What happened: Server offline, port closed, or firewall blocking.
Fix: Check that the service is running and listening on the expected port.

17. Fake or Expired ID — Certificate Issues (SSL Error)

Analogy: Security hands you an ID that looks fake, expired, or obviously forged.
What happened: Expired, mismatched, or self-signed SSL certificate.
Fix: Renew the certificate, fix hostname mismatches, or accept the risk in local dev.

18. Waiting Too Long — General Timeout (Timeout Error)

Analogy: You stood at the reception desk for 30 minutes waiting for a response, then finally gave up.
What happened: The server took too long to respond.
Fix: Increase timeout settings, optimize your request, or check your network connection

19. You Brought a Box of Stuff They Didn’t Ask For — Payload Too Large (413 Payload Too Large)

Analogy: You walked up to the front desk carrying a refrigerator-sized box of documents. The staff refuses it on sight.
What happened: You sent a request body that’s bigger than the server’s allowed limit.
Fix: Compress, shrink, paginate, or split the data. Don’t send the whole warehouse in one trip.

20. You Came Back Too Soon With Old Instructions — Precondition Failed (412 Precondition Failed)

Analogy: You told the clerk “only update this drawer if nobody else touched it,” but someone did.
What happened: Your request required the resource to be unchanged, but it updated meanwhile.
Fix: Refresh data first, then retry with new conditions. Useful in multi-editor or collaborative environments.

21. The City Redirects You Somewhere Else — Redirect Issues (301 / 302 / 307)

Analogy: You show up at one building, and the security guard says, “We moved—go two blocks north.”
What happened: The server redirects you, but your client didn’t follow it or got confused by too many redirects.
Fix: Allow redirects or update your base URL so you go directly to the new address.

22. Wrong File Format — Unsupported Media Type (415)

Analogy: You hand the clerk a VHS tape when their office only has Blu-ray players.
What happened: Your Content-Type doesn’t match what the server accepts.
Fix: Set the correct content type — most APIs expect application/json.

23. Too Many Redirects — Redirect Loop (310 / Browser Error)

Analogy: Security keeps sending you to another desk, and that desk sends you right back. Over and over.
What happened: Two or more endpoints are redirecting into a loop.
Fix: Check redirect logic. Clear cookies/cache if sessions are involved.

24. Building Under Renovation — API Version Deprecated (410 Gone)

Analogy: You showed up with last year’s floor plan, but that entire wing was demolished months ago.
What happened: You’re calling an API version that’s been retired.
Fix: Upgrade to the current API version. Check deprecation notices before things break.

25. Wrong Key for Drawer — Invalid Parameters (400 Bad Request)

Analogy: You try to unlock a numeric lock with letters. The clerk just stares.
What happened: Wrong data types, invalid enum values, or nonsense parameters.
Fix: Validate parameter types before sending the request.

26. Missing Required Paperwork — Required Fields Missing (422 Unprocessable Entity)

Analogy: You filled out the form but forgot to sign it and didn’t attach the required documents.
What happened: The data is correctly formatted, but required fields are missing.
Fix: Include all required fields. Check the API spec.

27. Building Quarantined — IP Blocked (403 Forbidden)

Analogy: Your entire office building is banned from entering — not just you.
What happened: Your IP or IP range is blocked by a firewall.
Fix: Change networks/VPN or request IP whitelisting.

28. Wrong Delivery Entrance — CORS Error (Browser Block)

Analogy: You’re trying to deliver packages through the employees-only entrance without the right paperwork.
What happened: The browser blocked your cross-origin request for security reasons.
Fix: Server must return correct CORS headers, or use a dev proxy.

29. Clerk Can’t Read Your Handwriting — Malformed JSON (400 Bad Request)

Analogy: You filled out the form with handwriting so messy the staff can’t read a single line.
What happened: Broken JSON — missing quotes, trailing commas, stray characters.
Fix: Validate and format your JSON. Use a linter.

30. Wrong Season Pass — Token Scope Issues (403 Forbidden)

Analogy: You have a summer pass but it’s winter. Or a daytime pass but it’s midnight.
What happened: Your token is valid but has the wrong scopes/permissions.
Fix: Request or generate a token with the correct scopes.

31. Building Capacity Reached — Resource Limits (509 Bandwidth Limit Exceeded)

Analogy: The building is physically full. Fire marshals say, “No more people today.”
What happened: You hit bandwidth caps, storage quotas, or high-tier usage limits.
Fix: Wait for reset, optimize usage, or upgrade your plan.

32. Wrong Security Clearance — API Key Restrictions (403 Forbidden)

Analogy: Your badge works, but only on weekdays — and today is Saturday.
What happened: Your API key is restricted by IP, referrer, domain, time window, or quota.
Fix: Check API key restrictions and update configuration.

33. Mixed Up Buildings — Wrong Environment (Staging vs Production)

Analogy: You accidentally went to the company training center instead of the actual headquarters.
What happened: You hit staging, wrong region, wrong datacenter, or a dev endpoint.
Fix: Double-check environment URLs and config variables.

34. Outdated Floor Directory — API Schema Changed

Analogy: The room numbers were reorganized, but you’re still using last month’s directory.
What happened: The API changed fields or response structure, but your code expects the old version.
Fix: Update your parsing logic. Handle breaking changes gracefully.

35. Wrong Queue — Content Negotiation Issues (406 Not Acceptable)

Analogy: You stand in the express lane with a full shopping cart and the clerk refuses to scan anything.
What happened: Your Accept header demands a format the server can’t produce.
Fix: Set a supported Accept header or remove it to accept defaults.

The errors basically are:

A. When You Can’t Even Reach the Building in the First Place
B. When You Reach the Building but Can’t Get Inside Any Department
C. When Security Stops You Before You Can Move Any Further
D. When You Enter the Building but Your Request Fails Inside the Lobby
E. When You Reach the Correct Room but the Resource You Want Isn’t There
F. When You Try to Make a Change but Run Into Conflicts or Clashes
G. When You’re Redirected Around the City in Confusing or Broken Ways
H. When the Building Tries to Handle Your Request but Breaks Internally
I. When You Overload the Building by Sending Too Much or Too Fast