← From Zero to Deployed Alle LektionenAll lessons Setup ModelleModels

Phase 1 · Grundlagen

03 · Internet und wie Computer sprechen

Du kannst erklären, wie ein Frontend über das Internet ein Backend erreicht.

Phase 1 · Foundations

03 · The Internet and how computers talk

You can explain how a frontend reaches a backend across the internet.

„Läuft auf meinem Laptop“ heißt: erreichbar nur für dich. „Im Internet“ heißt: erreichbar für alle. Der Unterschied ist eine öffentliche Adresse — und genau die schließt das Deployen am Ende auf. Wer versteht, wie Nachrichten reisen, kann Fehler viel schneller einordnen.

Die Idee

Das Internet ist wie ein riesiges Postsystem. Jeder Computer hat eine Adresse. Du schickst einen Brief („Zeig mir diese Seite“), der Empfänger schickt einen Brief zurück („Hier ist sie“). Mehr ist es im Kern nicht: Adressen und Zustellung.

Wenn du Instagram öffnest, schickt dein Handy Hunderte solcher Briefe: einen, um den Feed zu holen, einen pro Foto, einen wenn du ein Herz antippst. Jede Aktion ist ein kleiner Hin-und-zurück zwischen deinem Gerät und Instagrams Servern.

flowchart LR
    A[Dein Gerät] -->|Brief: gib mir den Feed| S[Instagram-Server]
    S -->|Brief: hier ist der Feed| A

So funktioniert es

Vier Begriffe genügen:

So läuft das Öffnen eines Feeds ab: dein Browser fragt DNS nach der Adresse, verbindet sich per HTTPS und stellt einen Request.

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant S as Instagram-Server
    B->>D: Wie lautet die IP von instagram.com?
    D-->>B: 203.0.113.5
    B->>S: GET /feed  (HTTPS)
    S-->>B: 200 OK + Beiträge als JSON

Ein HTTP-Request hat eine Methode, einen Pfad, Header und optional einen Body. So sieht ein vollständiger Request aus, wenn du auf Instagram einen Beitrag postest:

POST /api/posts HTTP/1.1
Host: instagram.example
Content-Type: application/json
Authorization: Bearer <token>

{
  "caption": "Sonnenuntergang über Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg"
}

Und die Response — mit Statuscode und Body:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "p_184029",
  "author": "anna",
  "caption": "Sonnenuntergang über Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg",
  "likeCount": 0,
  "createdAt": "2026-08-31T09:41:00Z"
}

Zeile für Zeile: POST ist die Methode (etwas anlegen), /api/posts der Pfad, Host sagt an welchen Server, Content-Type welches Format der Body hat, Authorization beweist wer du bist. Die Response 201 Created heißt „erfolgreich angelegt“ und schickt den fertigen Beitrag inklusive id und createdAt zurück.

So steuerst du es

Wichtige Statuscodes: 200 OK, 201 Erstellt, 400 schlechte Anfrage, 401 nicht eingeloggt, 403 verboten, 404 nicht gefunden, 500 Serverfehler. Ein häufiger Fehler ist, 200 zurückzugeben, obwohl etwas schiefging — dann kann das Frontend echte Fehler nicht erkennen und zeigt „gespeichert“, obwohl nichts gespeichert wurde.

HTTPS ist heute Pflicht: Über HTTP könnten Fremde Authorization-Token unterwegs mitlesen. Bei Cloud Run bekommst du HTTPS automatisch.

So sagst du es dem Agenten:

„Zeig mir für ‚Beitrag posten‘ den vollständigen HTTP-Request (Methode, Pfad, Header, Body) und die erwartete Response mit Statuscode.“

„Gib bei Fehlern passende Statuscodes zurück (400 bei ungültigem Body, 401 ohne Login), nicht immer 200.“

„Sende das Authorization-Token nur über HTTPS und niemals im Klartext in einer URL.“

Typische Fehler: Statuscodes ignorieren; Geheimnisse in die URL packen (landen in Server-Logs); oder annehmen, das Frontend müsse Fehler nicht behandeln.

Kurz-Check

  1. Was macht DNS?
  2. Woraus besteht ein HTTP-Request?
  3. Warum ist 201 Created besser als 200 OK, wenn ein Beitrag angelegt wurde?
Antworten anzeigen
  1. Es übersetzt einen Namen (instagram.com) in eine IP-Adresse.
  2. Aus Methode, Pfad, Headern und optional einem Body.
  3. 201 sagt genau „neu angelegt“; das Frontend weiß dadurch, dass die Erstellung geklappt hat, und kann z. B. die neue id verwenden.

"Runs on my laptop" means reachable only by you. "On the internet" means reachable by everyone. The difference is a public address — and that is exactly what deploying unlocks at the end. Understanding how messages travel lets you place bugs much faster.

The idea

The internet is like a giant postal system. Every computer has an address. You send a letter ("show me this page"), the recipient sends a letter back ("here it is"). At its core that is all it is: addresses and delivery.

When you open Instagram, your phone sends hundreds of such letters: one to fetch the feed, one per photo, one when you tap a heart. Every action is a small round trip between your device and Instagram's servers.

flowchart LR
    A[Your device] -->|letter: give me the feed| S[Instagram server]
    S -->|letter: here is the feed| A

How it works

Four terms are enough:

Here is how opening a feed goes: your browser asks DNS for the address, connects over HTTPS, and makes a request.

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant S as Instagram server
    B->>D: What is the IP of instagram.com?
    D-->>B: 203.0.113.5
    B->>S: GET /feed  (HTTPS)
    S-->>B: 200 OK + posts as JSON

An HTTP request has a method, a path, headers, and an optional body. Here is a complete request for posting on Instagram:

POST /api/posts HTTP/1.1
Host: instagram.example
Content-Type: application/json
Authorization: Bearer <token>

{
  "caption": "Sunset over Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg"
}

And the response — with a status code and body:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "p_184029",
  "author": "anna",
  "caption": "Sunset over Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg",
  "likeCount": 0,
  "createdAt": "2026-08-31T09:41:00Z"
}

Line by line: POST is the method (create something), /api/posts is the path, Host says which server, Content-Type says the body format, Authorization proves who you are. The response 201 Created means "successfully created" and sends back the finished post including its id and createdAt.

How you steer it

Important status codes: 200 OK, 201 Created, 400 bad request, 401 not signed in, 403 forbidden, 404 not found, 500 server error. A common mistake is returning 200 even when something failed — then the frontend cannot detect real errors and shows "saved" when nothing was saved.

HTTPS is mandatory today: over plain HTTP, strangers could read the Authorization token in transit. On Cloud Run you get HTTPS automatically.

How to tell the agent:

"For 'create a post', show me the full HTTP request (method, path, headers, body) and the expected response with a status code."

"Return proper status codes on failure (400 for an invalid body, 401 without login), not always 200."

"Send the Authorization token only over HTTPS and never in plain text inside a URL."

Common mistakes: ignoring status codes; putting secrets in the URL (they end up in server logs); or assuming the frontend need not handle errors.

Quick check

  1. What does DNS do?
  2. What does an HTTP request consist of?
  3. Why is 201 Created better than 200 OK when a post was created?
Show answers
  1. It translates a name (instagram.com) into an IP address.
  2. A method, a path, headers, and an optional body.
  3. 201 says precisely "newly created"; the frontend knows creation succeeded and can, for example, use the new id.