🌐

Vorlesung 6

HTTP & REST
Wie reden verteilte Anwendungen miteinander?

Verteilte Systeme
Prof. Dr. Alexandra Mikityuk
HTW Berlin

HTTP REST Web-APIs

Lernziele

Verstehen, wie das HTTP-Protokoll Request und Response strukturiert
Den Unterschied zwischen zustandslosen und zustandsbehafteten Servern erkennen — und warum HTTP zustandslos ist
Die REST-Prinzipien auf eigene Anwendungen anwenden können
Wissen, warum PUT idempotent ist und POST nicht — und wann ihr welches nutzt
Erkennen, dass die Claude API und Bitcoin-RPC aus den vorigen VLs nichts anderes sind als REST über HTTP

HTTP ist überall — wirklich überall

Egal was ihr in den letzten Wochen gebaut habt — unter der Haube lief immer HTTP.

🤖 VL 2-3: AI Agents

Jeder Aufruf an Claude, GPT oder Gemini ist ein HTTP POST an einen REST-Endpoint. Der Agent macht nichts magisches — er schickt JSON über HTTP.

⛓️ VL 4-5: Bitcoin

Bitcoin-Wallets reden mit Nodes per JSON-RPC über HTTP. Block Explorers, Exchange-APIs, Mempool-Daten — alles HTTP.

🌍 Web & IoT

Browser laden Webseiten per HTTP. Smart-Home-Geräte konfigurieren sich per REST. Sogar Drucker haben HTTP-APIs.

                Heute lernen wir, was unter der Haube passiert — damit ihr nicht nur API-Calls macht, sondern versteht, was wirklich übers Netzwerk geht.
            

Das Web basiert auf drei Konzepten

Tim Berners-Lee, 1989 am CERN. Drei Erfindungen — und das Internet wurde klickbar.

🏷️ URI / URL

Uniform Resource Identifier

Einheitliche Namensgebung und Lokalisierung von Ressourcen.

https://htw-berlin.de/...

📡 HTTP

Hyper Text Transfer Protocol

Zustandsloses Protokoll für den Datenaustausch zwischen Client und Server.

GET /index.html HTTP/1.1

📄 HTML

Hyper Text Markup Language

Textauszeichnungssprache zur Darstellung der Inhalte und für Hyperlinks.

                Heute Fokus: HTTP (Slides 5-15) und sein Architektur-Stil REST (Slides 16-22). HTML kennt ihr aus Grundlagen-Vorlesungen.
            

URI — die Adresse einer Ressource

Eine URI hat vier Teile (RFC 3986). Beispiel:

                    https://example.com:8080/update/person?id=42&email=alex%40example.com
                

■ Scheme ■ Authority ■ Path ■ Query (alles nach ?)

📋 Die vier Teile

Scheme: welches Protokoll (http, https, ftp...)
Authority: Host + Port (Port optional, Default 80 / 443)
Path: wo auf dem Server, mit / getrennte Segmente
Query: optional, key=value-Paare, mit & verbunden

🔍 URI vs URL vs URN

URI ist der Oberbegriff. Zwei Geschmacksrichtungen:

URL — sagt euch WO + WIE ihr hinkommt:
https://htw-berlin.de/info
→ das nutzt HTTP. Browser klickt drauf.
URN — sagt euch WAS es ist (Name), nicht wo:
urn:isbn:978-3-86680-192-9
→ das ist ein bestimmtes Buch. Nicht abrufbar.

Praxis: HTTP und ihr arbeitet ausschließlich mit URLs. URN ist nur Theorie-Vokabular — müsst ihr nicht aktiv nutzen, hilft nur zu verstehen, was „URI" eigentlich umfasst.

HTTP — das Frage-Antwort-Spiel

HTTP ist ein Request/Response-Protokoll. Client fragt, Server antwortet. Mehr nicht.

Client
(Browser, App, curl)

→

HTTP Request

→

Server
(nginx, Apache, ...)

Client

←

HTTP Response

←

Server

                Zustandslos: jeder Request ist unabhängig. Der Server merkt sich nichts. Ihr könnt 100 Requests parallel an 100 verschiedene Server schicken — alle antworten gleich. (Warum das ein Feature ist → Slide 12.)
            

                Aktuelle Spezifikation: HTTP/1.1 (RFC 7230-7235, 2014). Autoren: Berners-Lee, Fielding, Frystyk. HTTP/2 und HTTP/3 sind Performance-Optimierungen, die Semantik bleibt.
            

HTTP-Methoden — was will ich tun?

Jeder Request hat eine Methode. Sie sagt dem Server, was mit der Ressource passieren soll.

Methode	Bedeutung	Body?
GET	Ressource abrufen (lesen). Häufigste Methode.	Nein
HEAD	Wie GET, aber nur Header — keine Daten. Z. B. zum Cachen prüfen.	Nein
POST	Daten an Server schicken — typisch: neue Ressource erzeugen.	Ja
PUT	Ressource an dieser URI vollständig setzen/ersetzen.	Ja
PATCH	Ressource teilweise aktualisieren.	Ja
DELETE	Ressource an dieser URI löschen.	Nein
OPTIONS	Welche Methoden unterstützt der Server für diese URI?	Nein

                Die Methoden sind ein Vertrag. Niemand erzwingt ihn — aber alle Tools verlassen sich drauf. Was passiert, wenn jemand den Vertrag bricht? → nächste Slide.
            

Wer entscheidet, was GET wirklich tut? — Die GET-Falle

HTTP-Methoden sind eine Empfehlung, kein Zwang. Was passiert, hängt von drei Akteuren ab — und genau hier lauert die Falle.

1️⃣ HTTP-Spec

Sagt: „GET sollte lesen, nichts ändern."

Aber: das ist nur eine Empfehlung. HTTP erzwingt nichts.

→

2️⃣ Server-Code

Programmiert für jede URL, was wirklich passiert.

Euer Code könnte bei GET auch löschen — technisch erlaubt.

→

3️⃣ Tooling

Browser, Crawler, Prefetcher vertrauen: GET ist sicher.

Sie rufen GET-Links einfach auf — ohne zu fragen.

💥 Die Falle in Aktion — historisches Beispiel

Naiver Admin-Lösch-Link:

<a href="/delete?id=42">Löschen</a>

Server-Code: „GET auf /delete?id=42 → lösche Kommentar 42."

Admin-Klick = passt. Aber wer ruft die URL noch auf, ohne zu fragen?

Die stillen Mit-Klicker:

Google-/Bing-Crawler indexieren alle Links
Link-Prefetcher im Browser laden vorab
Antivirus / Spam-Scanner öffnen jeden Link
Link-Vorschauen in Slack, Teams, WhatsApp

2005: Googles Web Accelerator rief Admin-Links vorab ab, um sie zu cachen → Kommentare verschwanden weltweit, ohne dass jemand „Löschen" geklickt hatte.

                „Kann ich also den ganzen Server löschen, indem ich Links öffne?" Nein. Eine GET-Anfrage tut nur das, was der Server-Code für diese URL programmiert hat. Von außen könnt ihr nichts Beliebiges auslösen. Das Problem entsteht nur, wenn euer eigener Server destruktive Aktionen an GET koppelt.
            

                Die Regel: GET muss sicher sein — keine Seiteneffekte. Verändern oder Löschen → POST / PUT / DELETE.
            

HTTP-Status-Codes — wie ist's gelaufen?

Jede Response beginnt mit einer Zahl. Die erste Ziffer sagt euch sofort, was passiert ist.

2XX — Success

200 OK — alles bestens, hier deine Daten
201 Created — Ressource erzeugt (nach POST/PUT)
204 No Content — OK, aber keine Antwort-Daten

3XX — Redirection

301 Moved Permanently — neue Adresse, merk's dir
302 Found — diesmal woanders, später zurück
304 Not Modified — du hast die aktuelle Version (Cache!)

4XX / 5XX — Fehler

400 Bad Request — Request kaputt
401 Unauthorized — log dich ein
403 Forbidden — du nicht
404 Not Found — gibt's nicht
500 Internal Server Error — Server hat Schluckauf

                Merkregel: 4XX = du hast was falsch gemacht (Client-Fehler). 5XX = der Server hat ein Problem.
            

Wie sieht eine HTTP-Nachricht aus?

Drei Teile: Startzeile + Header + optionaler Body. Header und Body sind durch eine Leerzeile getrennt.

📤 Request

GET /people/detail/965/ HTTP/1.1
Host: www.htw-berlin.de
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xml
Accept-Language: de-de
Cookie: session=abc123...
Connection: keep-alive

(bei POST/PUT: hier kommt der Body)

📥 Response

HTTP/1.1 200 OK
Date: Sun, 07 Jun 2026 11:32:22 GMT
Server: nginx/1.24
Set-Cookie: session=xyz789; path=/
Content-Type: text/html;charset=utf-8
Content-Length: 1842

<!DOCTYPE html>
<html>...</html>

                Headers sind Meta-Daten: Content-Type sagt dem Browser „rendere mich als HTML". application/json → JSON parsen. image/png → als Bild anzeigen. Stammt aus dem E-Mail-Standard MIME (RFC 2045).
            

Eine echte HTTP-Session — von vorne

Was passiert, wenn ihr www.heise.de in den Browser tippt?

DNS-Lookup: Browser fragt: „IP von www.heise.de?" → DNS-Server antwortet: 193.99.144.85
TCP-Handshake: Browser baut TCP-Verbindung zu 193.99.144.85:80 auf (bei HTTPS: Port 443)
HTTP-Request: GET / HTTP/1.1\nHost: www.heise.de
HTTP-Response: Server schickt HTML zurück
Browser parst HTML, findet eingebettete Bilder, CSS, JS
Weitere Requests: für jede Ressource ein neuer GET (oft über dieselbe TCP-Verbindung)
Rendering: Browser baut die Seite zusammen und zeigt sie an

                🔍 Live-Demo: öffnet die Browser-DevTools (F12) → Tab „Network" → lädt eine Seite neu. Ihr seht jeden einzelnen Request, Status-Code, Headers, Timing. Probiert's gleich mit der Claude-Web-App — ihr seht REST-Calls live.
            

Zustandsbehaftet vs. zustandslos — die fundamentale Frage

Soll der Server sich merken, wer du bist? Beide Wege haben Vor- und Nachteile.

🧠 Zustandsbehafteter Server

Der Server speichert eine Session für jeden Client. Logische Verbindung über mehrere Anfragen hinweg.

Vorteile: performant (Daten im RAM), einfache App-Logik.

Nachteile: Skalierung schwer (Session-Sync zwischen Servern), verwaiste Sessions.

Beispiele: SMTP (E-Mail), SSH, FTP, Distributed File Systems.

💨 Zustandsloser Server

Der Server speichert nichts. Jeder Request bringt alle nötigen Infos mit.

Vorteile: einfache Recovery (Crash? → Retry), horizontale Skalierung (load balancing), Caching möglich.

Nachteile: längere Nachrichten (Overhead), Anwendungslogik aufwendiger.

Beispiele: HTTP (und damit REST).

                Warum hat HTTP sich für zustandslos entschieden? Weil das Web weltweit skalieren muss. 1 Mrd. User × 100 Requests/Tag — kein einziger Server kann das. Zustandslos = jeder Server kann jeden Request beantworten = Load Balancing trivial.
            

Cookies — State in einem zustandslosen Protokoll

Aber Login, Warenkorb, Personalisierung brauchen doch Zustand. Die Lösung: der Client speichert ihn.

🍪 Wie Cookies funktionieren — 3 Schritte

Bei der ersten Antwort setzt der Server einen Cookie:
Set-Cookie: session_id=abc123; path=/
Der Browser speichert den Cookie lokal.
Bei jedem weiteren Request an dieselbe Domain schickt der Browser ihn mit:
Cookie: session_id=abc123

                Der Trick: der Server bleibt zustandslos — er bekommt mit jedem Request die Identität mitgeliefert. Was er mit der session_id macht (DB-Lookup, JWT prüfen, ...) ist Server-interne Sache.
            

                Erfunden Mitte der 1990er bei Netscape — weil ohne Cookies kein Online-Shopping ginge. Heute auch: Authorization: Bearer <jwt-token> als Alternative für moderne APIs (Claude, GitHub, ...).
            

Warum HTTP gewonnen hat

HTTP war nicht das erste, nicht das beste Protokoll. Es ist aus folgenden Gründen Standard geworden:

🔓 Firewall-freundlich

Port 80 (HTTP) und 443 (HTTPS) sind überall offen. Eigene Protokolle scheitern an Corporate-Firewalls — HTTP kommt durch.

📈 Skalierbar

HTTP-Server (nginx, Apache, Caddy) sind hochoptimiert. Millionen Requests/Sek. Caching, Load Balancing, CDNs — alles built-in.

🛠️ Universell-tunnelbar

SOAP, gRPC, GraphQL, JSON-RPC, Video-Streaming — alle verstecken sich in HTTP. „If in doubt, tunnel through HTTP."

🔒 TLS-erweiterbar

HTTPS = HTTP über TLS. Verschlüsselung, Datenintegrität, Authentifikation. Heute Standard — http:// Seiten warnt jeder Browser.

Performance — der TCP-Overhead-Trick

Eine HTTP-Nachricht ist klein. Aber jede TCP-Verbindung kostet einen 3-way Handshake (drei Pakete zum Aufbau: SYN → SYN-ACK → ACK) — bei 50 Requests pro Webseite ist das viel Latenz.

🐢 Klassisch (HTTP/1.0)

Pro Request neue TCP-Verbindung
3-way Handshake = 1 RTT pro Verbindungsaufbau
50 Bilder = 50 × Handshake = viel Wartezeit

OK für 1 Doc, schlecht fürs moderne Web.

🚀 Persistent Connections (HTTP/1.1)

Eine TCP-Verbindung, viele Requests
Connection: keep-alive Header
Pipelining: nächsten Request schicken, ohne auf Antwort zu warten

TCP-Stack lernt die Verbindung kennen → kann verlorene Pakete schneller erneut senden.

HTTP/2 & HTTP/3 gehen weiter:

Multiplexing — viele Requests parallel über eine Verbindung statt nacheinander
Header-Komprimierung — Header wiederholen sich oft, komprimiert spart Bandbreite
Server Push — Server schickt Ressourcen mit, bevor der Client sie anfragt
HTTP/3 nutzt QUIC statt TCP — neuerer Transport von Google, schnellerer Verbindungsaufbau

Die Semantik (Methoden, Status-Codes) bleibt gleich — das, was wir heute lernen, gilt für alle Versionen.

                💡 Abkürzungs-Zoo
                RTT = Round-Trip Time — wie lange ein Paket hin und zurück braucht. Das Latenz-Maß im Netzwerk.
QUIC = Quick UDP Internet Connections — moderner Transport-Standard, ersetzt TCP in HTTP/3 für weniger Latenz beim Verbindungsaufbau.
SYN / ACK = Synchronize / Acknowledge — die TCP-Steuerflags für „neue Verbindung" bzw. „bestätigt".

            

Caching — Inhalte näher zum Nutzer bringen

Warum jede Anfrage an den Origin-Server schicken, wenn sich der Inhalt gar nicht geändert hat?

🖥️ Browser-Cache

Lokal auf deinem Rechner. Bilder, CSS, JS — schon auf der Platte? Direkt anzeigen. Cache-Control Header steuern wie lange.

🏢 Proxy-Cache

Im Firmen- oder ISP-Netz. Spart Traffic. Heute weniger wichtig, weil HTTPS-Inhalte für Proxies opak sind.

🌍 CDN

Content Delivery Network (Akamai, Cloudflare, Fastly). Server weltweit verteilt. User aus Berlin → Server in Frankfurt. Niedrige Latenz, weniger Last auf Origin.

                Cache-Validierung mit 304 Not Modified: Browser fragt den Server „hat sich die Ressource seit Datum X geändert?" — wenn nicht, antwortet der Server mit 304 (kein Body!) und der Browser nimmt seine lokale Kopie. Schnell & sparsam.
            

Web-Architektur — drei Rollen

Jede HTTP-Komponente spielt eine dieser drei Rollen — manchmal sogar mehrere gleichzeitig.

📥 Client

Schickt Requests, empfängt Responses, wertet sie aus.

Beispiele: Browser, Smartphone-App, Python-Skript mit requests, curl, Crawler.

📤 Server

Empfängt Requests, schickt Responses. Liefert vorgefertigte oder dynamisch generierte Inhalte.

Beispiele: nginx, Apache, Caddy, Node.js-App, FastAPI, Django, Flask.

🔄 Proxy

Server gegenüber dem Client, Client gegenüber dem Server. „Steht in der Mitte."

Funktionen: Caching, Logging, Anonymisierung, Access Control, Transcoding, TLS-Termination.

                Praxis: ein CDN ist ein Proxy. Ein Load Balancer ist ein Proxy. Eine API-Gateway ist ein Proxy. Die Proxy-Rolle ist die flexibelste in der HTTP-Welt — fast jede moderne Architektur hat irgendwo einen Proxy drin.
            

Von HTTP zu REST — die nächste Abstraktion

HTTP ist ein Protokoll. REST ist eine Idee, wie man HTTP elegant nutzt, um APIs zu bauen.

📜 Die Geschichte:

Roy Fielding (einer der HTTP-Autoren!) schrieb 2000 seine Doktorarbeit: „Architectural Styles and the Design of Network-based Software Architectures".

Er beschrieb darin den Architektur-Stil REST — REpresentational State Transfer. Die Idee: nutzt HTTP wie es gemeint war, statt eigene RPC-Protokolle daraufzubasteln.

🐘 Alte Welt: RPC/SOAP

Domänen-spezifische Methoden: getProductPrice(id), setUserEmail(id, email). XML-Pakete, WSDL-Definitionen, kompliziert.

🪶 REST

Universelle Verben (GET, POST, PUT, DELETE) auf Ressourcen via URI. Leichtgewichtig, JSON-Antwort, jeder versteht's.

REST-Prinzipien — Ressourcen statt Methoden

In REST denkt ihr nicht in „Funktionen", sondern in Ressourcen — Dinge, die eine eigene URI haben.

🎯 Eine Ressource ist:

Identifiziert durch eine logische URL: /users/42, /orders/2026-07-12, /messages
Repräsentiert Zustand (Daten) und Funktionalität (was man damit machen darf)
Universell ansprechbar — jeder im System kann die URI nutzen

                CRUD → HTTP-Methoden:
                
                    AktionHTTPBeispiel

                    CreatePOSTPOST /users (mit Body)
ReadGETGET /users/42
UpdatePUT / PATCHPUT /users/42 (mit neuem Body)
DeleteDELETEDELETE /users/42

Aktion	HTTP	Beispiel
Create	POST	`POST /users` (mit Body)
Read	GET	`GET /users/42`
Update	PUT / PATCH	`PUT /users/42` (mit neuem Body)
Delete	DELETE	`DELETE /users/42`

PUT vs. POST — der Idempotenz-Unterschied

Beide ändern Daten am Server. Aber sie unterscheiden sich in einer wichtigen Eigenschaft:

🔁 PUT — idempotent

„Setze die Ressource an dieser URI auf genau diesen Wert."

PUT /users/42 HTTP/1.1
Content-Type: application/json

{"name": "Alex", "age": 29}

Idempotent: egal ob ihr das 1× oder 100× schickt — das Ergebnis ist dasselbe. User 42 hat danach Name „Alex".

➕ POST — nicht idempotent

„Erzeuge eine neue Ressource unter dieser URI" (Child-Ressource).

POST /users HTTP/1.1
Content-Type: application/json

{"name": "Alex"}

Nicht idempotent: 5× schicken → 5 verschiedene User. Server vergibt jedes Mal eine neue ID.

                Praxis-Regel: wenn der Client die ID/URI schon kennt → PUT. Wenn der Server eine neue ID vergibt → POST. Idempotenz ist wichtig für Retry-Logik: bei Netzwerkfehler kann der Client PUT einfach nochmal schicken — POST nicht.
            

REST in Aktion — ein echtes Beispiel

REST-APIs liefern fast immer JSON. Hier eine typische Interaktion:

📤 Request

GET /api/users/42 HTTP/1.1
Host: api.htw-berlin.de
Accept: application/json
Authorization: Bearer eyJhbGc...

📥 Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alex",
  "role": "student"
}

                💡 Warum JSON? JavaScript Object Notation (RFC 8259) — entstand 2001 für JavaScript, ist heute der Lingua Franca aller Web-APIs. Vorteile gegenüber XML: kompakter, leichter lesbar, typisiert (Number, String, Boolean, Null, Array, Object). Reduzierter Overhead = schneller.
            

Vom Konzept zum Code — wie ruft man eine API auf?

Bisher abstrakt — jetzt konkret. Wir nutzen httpbin.org: ein Echo-Server, der euch zurückspiegelt, was ihr schickt — perfekt zum Lernen.

🖥️ Terminal — `curl`

# GET-Request mit Query-Parameter
$ curl "https://httpbin.org/get?name=alex"

# Antwort vom Server (JSON):
{
  "args": {"name": "alex"},
  "url": "https://httpbin.org/get?..."
}

Was passiert hier — Schritt für Schritt:

1. curl liest die URL und baut intern einen HTTP-GET-Request
2. öffnet TCP-Verbindung zu httpbin.org:443 (HTTPS)
3. schickt GET /get?name=alex HTTP/1.1
4. empfängt die Response und druckt den Body ins Terminal

curl = der Standard zum HTTP-Debugging. Auf jedem Mac/Linux schon dabei.

🐍 Python — `requests`

import requests

response = requests.get(
    "https://httpbin.org/get",
    params={"name": "alex"}
)

# Status und Body lesen
print(response.status_code)  # 200
data = response.json()
print(data["args"])         # {'name': 'alex'}

Was passiert hier — Schritt für Schritt:

1. requests.get(url, params={...}) — Library baut + schickt den Request
2. params= wird automatisch URL-encoded (z.B. Leerzeichen → %20)
3. response.status_code = die 200
4. response.json() = JSON-Body → Python-Dict

pip install requests — Standard-Library für HTTP in Python.

                Beide tun exakt dasselbe — sie bauen den HTTP-Request, schicken ihn übers Netz, empfangen die Response. curl zum Debuggen im Terminal, requests in eurem Code. Genau diese zwei Tools brauchen 99% der Devs im Alltag.
            

REST in eurem Alltag — die Brücke zurück

Erinnert ihr euch an die letzten VLs? Schaut, was wirklich passiert ist:

🤖 VL 2-3: Claude API

POST /v1/messages HTTP/1.1
Host: api.anthropic.com
Authorization: Bearer sk-ant-...
Content-Type: application/json

{
  "model": "claude-opus-4-7",
  "messages": [...]
}

Ihr habt einen REST-Endpoint aufgerufen — mehr nicht.

⛓️ VL 4-5: Bitcoin RPC

POST / HTTP/1.1
Host: bitcoin-node:8332
Content-Type: application/json

{
  "method": "getblockchaininfo",
  "params": []
}

JSON-RPC ist auch nur POST + JSON.

                Aha-Moment: alles, was ihr in den letzten Wochen mit „Agents", „LLM-APIs", „Bitcoin-Nodes" gemacht habt — das ist im Kern HTTP + JSON. Versteht ihr HTTP, versteht ihr 80% der modernen verteilten Welt.
            

REST & Sicherheit — eingebaut: nix

REST hat keine eingebauten Sicherheitsfeatures. Das ist Absicht — Sicherheit kommt von außen.

🔒 Transport: HTTPS

Immer TLS nutzen. https:// verschlüsselt Headers, Body, alles. Ohne TLS sind eure Tokens im Klartext im Netz.

🪪 Authentifizierung

Klassisch: Username/Passwort + Session-Cookie. Modern: Token im Authorization-Header (z.B. JWT oder OAuth2 Bearer Tokens).

🛡️ Berechtigung

Pro Endpoint prüfen: darf dieser User auf diese Ressource? Klassisch: Rollen (RBAC). Modern: feingranulare Policies, Scopes.

                ⚠️ Häufige Anfänger-Fehler:
                API-Keys ins Frontend einbauen → jeder sieht sie in DevTools
Authentifizierung im Frontend statt im Backend
HTTPS „später dazu" — nein, von Anfang an
Keine Rate-Limits → Angreifer probieren Passwörter milliardenfach

            

🤔 Mini-Quiz

Eine REST-API für eine Bank-App: welche HTTP-Methode für „neue Überweisung anlegen"?

A) GET — wir holen ja eine Überweisung ab

B) POST — wir erzeugen eine neue Ressource, Server vergibt die ID

C) PUT — wir setzen die Überweisung auf einen festen Wert

D) DELETE — die alte Überweisung wird ersetzt

                Warum B: der Client kennt die ID der neuen Überweisung noch nicht — der Server vergibt sie. Das ist genau der POST-Fall. Wichtig bei Geldgeschäften: POST ist nicht idempotent — bei Retry-Logik müsst ihr aufpassen, sonst wird die Überweisung doppelt ausgeführt! (Lösung: Idempotency-Keys vom Client mitschicken.)
            

Zusammenfassung — in einer Slide

HTTP = Request/Response-Protokoll mit Methoden (GET, POST, PUT, DELETE, ...), Status-Codes (2XX, 4XX, 5XX) und Headers.
Zustandslos: jeder Request unabhängig. Skaliert horizontal, einfach zu cachen. Bei Bedarf: Cookies für State auf Client-Seite.
URI/URL = einheitliche Namensgebung für Ressourcen. HTML = Inhalt. Drei Säulen des Web.
REST = Architektur-Stil: denkt in Ressourcen mit URIs, nutzt HTTP-Verben für CRUD. JSON als Datenformat.
PUT ist idempotent (sicher mehrfach ausführbar), POST nicht (erzeugt jedes Mal Neues).
Sicherheit: HTTPS, Tokens (JWT, OAuth2), Rate-Limits — REST selbst hat nichts eingebaut.
Erkenntnis: Claude API, Bitcoin RPC, GitHub API, fast jede Web-App — sind im Kern HTTP + JSON. Eine Sprache, viele Anwendungen.

📚 Quellen & weiterführende Literatur

Wo ihr tiefer einsteigen könnt:

📖 Standards (RFCs)

RFC 7230-7235 — HTTP/1.1 (Berners-Lee, Fielding et al., 2014)
RFC 3986 — Uniform Resource Identifier (URI)
RFC 8259 — JSON Data Interchange Format
RFC 9110-9114 — HTTP Semantics + HTTP/2 + HTTP/3 (aktuell, 2022)
RFC 6750 — OAuth 2.0 Bearer Token Usage

🔬 Akademisch

Fielding, R. (2000): „Architectural Styles and the Design of Network-based Software Architectures" — die Original-REST-Dissertation
Kurose & Ross: Computer Networking: A Top-Down Approach
Tanenbaum: Verteilte Systeme — Prinzipien und Paradigmen
Vorlesungsskript: Prof. T. Scheffler, Verteilte Systeme, HTW Berlin (2022) — Basis dieser VL

🛠️ Tools zum Ausprobieren

Browser DevTools (F12 → Network) — jeder Request live
curl — Standard-CLI für HTTP-Requests
Postman / Insomnia — GUI für REST-APIs
httpbin.org — Test-Endpoint für alle HTTP-Methoden

🎥 Zum Anschauen & Lesen

MDN Web Docs — beste Referenz für HTTP, kostenlos
HTTP/2 in Action (Manning, Pollard)
REST API Design Rulebook (Massé, O'Reilly)
http.cat — alle Status-Codes als Katzenbilder (ja, wirklich)

Vielen Dank!

Fragen?

Prof. Dr. Alexandra Mikityuk

HTW Berlin · Büro Raum 308

Tel +49 30 5019-2664

Nächste Woche: MQTT & Publish/Subscribe — die andere Hälfte der verteilten Kommunikation

Vorlesung 6

HTTP & RESTWie reden verteilte Anwendungen miteinander?

Lernziele

HTTP ist überall — wirklich überall

🤖 VL 2-3: AI Agents

⛓️ VL 4-5: Bitcoin

🌍 Web & IoT

Das Web basiert auf drei Konzepten

🏷️ URI / URL

📡 HTTP

📄 HTML

URI — die Adresse einer Ressource

📋 Die vier Teile

🔍 URI vs URL vs URN

HTTP — das Frage-Antwort-Spiel

HTTP-Methoden — was will ich tun?

Wer entscheidet, was GET wirklich tut? — Die GET-Falle

1️⃣ HTTP-Spec

2️⃣ Server-Code

3️⃣ Tooling

💥 Die Falle in Aktion — historisches Beispiel

HTTP-Status-Codes — wie ist's gelaufen?

2XX — Success

3XX — Redirection

4XX / 5XX — Fehler

Wie sieht eine HTTP-Nachricht aus?

📤 Request

📥 Response

Eine echte HTTP-Session — von vorne

Zustandsbehaftet vs. zustandslos — die fundamentale Frage

🧠 Zustandsbehafteter Server

💨 Zustandsloser Server

Cookies — State in einem zustandslosen Protokoll

🍪 Wie Cookies funktionieren — 3 Schritte

Warum HTTP gewonnen hat

🔓 Firewall-freundlich

📈 Skalierbar

🛠️ Universell-tunnelbar

🔒 TLS-erweiterbar

Performance — der TCP-Overhead-Trick

🐢 Klassisch (HTTP/1.0)

🚀 Persistent Connections (HTTP/1.1)

Caching — Inhalte näher zum Nutzer bringen

🖥️ Browser-Cache

🏢 Proxy-Cache

🌍 CDN

Web-Architektur — drei Rollen

📥 Client

📤 Server

🔄 Proxy

Von HTTP zu REST — die nächste Abstraktion

📜 Die Geschichte:

🐘 Alte Welt: RPC/SOAP

🪶 REST

REST-Prinzipien — Ressourcen statt Methoden

🎯 Eine Ressource ist:

PUT vs. POST — der Idempotenz-Unterschied

🔁 PUT — idempotent

➕ POST — nicht idempotent

REST in Aktion — ein echtes Beispiel

📤 Request

📥 Response

Vom Konzept zum Code — wie ruft man eine API auf?

🖥️ Terminal — curl

🐍 Python — requests

REST in eurem Alltag — die Brücke zurück

🤖 VL 2-3: Claude API

⛓️ VL 4-5: Bitcoin RPC

REST & Sicherheit — eingebaut: nix

🔒 Transport: HTTPS

🪪 Authentifizierung

🛡️ Berechtigung

🤔 Mini-Quiz

Eine REST-API für eine Bank-App: welche HTTP-Methode für „neue Überweisung anlegen"?

Zusammenfassung — in einer Slide

📚 Quellen & weiterführende Literatur

📖 Standards (RFCs)

🔬 Akademisch

🛠️ Tools zum Ausprobieren

🎥 Zum Anschauen & Lesen

HTTP & REST
Wie reden verteilte Anwendungen miteinander?

🖥️ Terminal — `curl`

🐍 Python — `requests`