Bisher spielt sich alles Wesentliche auf dem Client (im Browser) ab. Die TicTacToe-App kann zwar übers Internet ausgeliefert werden, aber nach der Übertragung der drei Dateien (HTML, CSS & JS) fliessen keine Daten mehr zwischen Browser und Server.

Insbesondere ist es auch nicht möglich, übers Netz gegeneinander zu spielen. Dafür müsste die Spiel-Logik nicht in Browser (also im Client) ausgeführt werden, sondern in einem Programm, das auf dem Server läuft. Die beiden Spieler:innen verbinden sich mit dem Server und rufen bestimmte Internetseiten auf, um den Zustand des Spiels zu verändern.

Wir trennen also die Darstellung (HTML & CSS) von der Spiellogik ab. Die Logik soll auf dem Server ausgeführt werden, die Browser rufen lediglich geeignete Schnittstellen (en. Application Programming Interface oder API) auf. Bei einer Web-App erfolgt der Aufruf der Schnittstelle über eine HTTP-Anfrage.

Das HyperText Transfer Protocol dient der Übertragung von Informationen zwischen Server und Client (Browser). Bisher haben wir ausschliesslich ganze Dateien (tictactoe.html, tictactoe.css, tictactoe.js) übertragen, aber HTTP kann noch mehr. Wir schauen uns an, was passiert, wenn wir auf unsere Webapp zugreifen. In den DevTools zeigen wir den Network Tab, wo die Folge der HTTP Requests angezeigt werden.

Jeder Request verlangt eine bestimmte Ressource (bisher: eine Datei) mit einer bestimmten Method. Die Method beschreibt die Aktion, typischerweise GET, um eine Ressource zu holen, POST um eine Ressource auf dem Server zu verändern.

Der Request enthält eine Anzahl zusätzlicher Informationen als Headers, insbesondere:

• If-modified-since: <timestamp>
  • Das Dokument nur zurückgeben, wenn es seit dem Zeitstempel verändert wurde.
  • Sonst antwortet der Server mit einem 304 Response Code, um Caching zu ermöglichen, so dass nicht immer die ganze Seite übertragen werden muss.
• Referer: Welche Seite oder Host hat die Anfrage ausgelöst.
  • wird dazu verwendet, das Surfverhalten von Nutzern zu analysieren
• User-agent:
  • Enthält Informationen zum Browser des Benutzers.
  • Kann zum Beispiel verwendet werden, um ein Mobiltelefon von einem Desktop-Computer zu unterscheiden.

Der Server antwortet mit einem Response Code und zusätzlichen Informationen, zum Beispiel der angeforderten Ressource. Die wichtigsten Codes sind:

• 200 (OK): Anfrage ist erfolgreich, die Ressource ist im Response Body enthalten.
• 304 (UNMODIFIED): Anfrage ist in Ordnung, die Ressource ist unverändert und wird darum nicht zurückgegeben (Nur bei GET, nicht bei POST)
• 404 (NOT FOUND): Die Ressource wurde nicht gefunden.

Zusätzlich kann der Server noch Cookies mitliefern, die der Browser speichert und beim nächsten Request an den gleichen Server im Request mitgeliefert werden.

Session-Cookies leben nur, solange das Browser-Fenster offen ist und sind in der Regel unproblematisch. Long-lived cookies können über Jahre installiert bleiben und bei jedem Seitenbesuch erneuert werden. Sie werden zum Teil benützt, um Benutzer über Webseiten hinweg zu verfolgen, und haben zur ganzen Diskussion um Cookies geführt. Um den Benutzer zu identifizieren (zum Beispiel nach erfolgreichem Login) sind sie aber unverzichtbar.