Client und Server: Wer fragt und wer antwortet

Auf os:1 hast du ein einziges Programm auf einer einzigen Maschine verfolgt: Es bekommt ein Stück CPU, ihm gehören ein paar Seiten Speicher, und man kann es anhalten und wieder fortsetzen. Auf networking:1 hast du eine einzige Anfrage rund um den Planeten verfolgt: Sie findet einen Host, sie öffnet eine TCP-Verbindung, sie kommt als Antwort zurück. Architektur fängt dort an, wo diese beiden sich treffen. In dem Moment, in dem dein Programm mit einem Programm auf einer anderen Maschine spricht, schreibst du nicht mehr ein Programm. Du ziehst eine Linie zwischen zwei Programmen, und fast jede Entscheidung danach hängt davon ab, wo du diese Linie ziehst.

Der Client ist das Programm, das das Gespräch beginnt. Er hat einen Bildschirm, einen Nutzer und keine Ahnung, was die richtige Antwort ist. Der Server ist das Programm, das auf Gespräche wartet, die Daten hält und entscheidet, was mit jeder Anfrage passiert. Das ist die ganze Definition, und sie sagt nichts über die Größe: Ein Handy kann ein Client sein, aber dasselbe Handy kann auch einen Server laufen lassen; ein Laptop ist ein Server, solange er für deine Freunde ein Spiel hostet. Etwas ist ein Server, weil er Anfragen beantwortet, die er nicht selbst gestartet hat, und weil die Anfragen anderer Leute ankommen, egal ob er gerade bereit ist oder nicht.

GET /orders/77 HTTP/1.1
Host: shop.example
Authorization: Bearer eyJhbGciOi...


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

{"id": 77, "total": 12.90, "status": "paid"}

Hier ist die Regel, die fast alles entscheidet: Der Client gehört dir nicht. Er läuft auf dem Rechner von jemand anderem, in einem Netzwerk, das du nicht kontrollierst, und sein Code lässt sich in den Entwicklerwerkzeugen eines Browsers in etwa zehn Sekunden lesen und ändern. Der Server darf einem Client also niemals glauben. "Ich bin Nutzer 5" ist eine Behauptung, keine Tatsache. Der Server muss sie gegen etwas prüfen, das der Client nicht fälschen kann, meistens ein Token, das auf dem Server signiert wurde. Ein Preis, den der Browser schickt, ist ein Vorschlag, der aus der Datenbank neu berechnet werden muss, und niemals eine Zahl, die man abrechnet.

Ein Server, der zwischen den Anfragen nichts behält, heißt zustandslos (stateless). Er bekommt eine Anfrage, erzeugt eine Antwort und vergisst, dass es die Anfrage je gab. Das klingt nach einem Rückschritt, ist aber der Grund, warum ein einziger Server eine Million Leute schaffen kann: Nichts an dir hängt an genau dieser Maschine, also kann deine nächste Anfrage bei irgendeinem von zwanzig gleichen Servern landen. Alles, was zwischen den Anfragen erhalten bleiben muss — ein Warenkorb, ein Login —, wird irgendwo gemeinsam gespeichert: in einer Datenbank, in einem Cache oder in einem signierten Token, das der Client mit sich herumträgt. Das ist dieselbe Idee wie bei HTTP im Netzwerk-Kapitel, jetzt aber als Entscheidung für die Architektur.