Klickt jemand einen Link an, passiert scheinbar nichts Besonderes. Doch genau in diesem Moment beginnt ein streng geregelter Dialog.
Erklärt wird das Anfrage-Antwort-Muster des Webs: Der Client fragt, der Server antwortet. Es passiert bei jedem Seitenaufruf, ob Browser, Smartphone-App oder Kommandozeile.
Zuerst tippt jemand eine Adresse ein, etwa eine mit Schema https, einem Host und dem Pfad zu einem Artikel. Der Browser zerlegt sie: Das Schema nennt die Art des Zugriffs, der Host den Zielrechner, der Pfad die Ressource. Der Browser ist hier der Client, also das Programm, das fragt. Das muss kein Browser sein; auch curl oder eine Mobile-App können diese Rolle übernehmen.
Dann baut der Client daraus eine HTTP-Anfrage, die Nachrichtenform des Webs. Sie besteht aus Methode, Ziel, Headern und optionalem Body. Die Methode sagt, was gewollt ist, etwa GET für reines Abfragen. Header sind kleine Zusatzinformationen.
Danach sendet der Client diese Anfrage an den Server, also das Programm, das antwortet. Der Server wartet nur; von sich aus schickt er nichts. Ohne vorherige Anfrage kommt keine Nachricht zurück. Die Begriffe Client und Server bezeichnen Rollen, keine Geräte. Wer fragt, bleibt in diesem Vorgang Client, auch wenn die Antwort aus Daten besteht.
Zuletzt antwortet der Server mit Statuscode, Headern und optionalem Body. Der Statuscode 200 meldet Erfolg, 404, dass der Server die Ressource unter diesem Pfad nicht findet. Die Antwort ist eine Darstellung der Ressource, etwa HTML für den Browser oder JSON-Daten für ein Programm. Da HTTP zustandslos ist, muss jede Anfrage alles nennen, was der Server zum Antworten braucht. Der Server weiß nie, was der Browser gerade anzeigt.
Wer denkt, Server könnten pushen, verwechselt Muster mit Ausnahmen.
📌 Anfrage-Antwort-Muster · Client und Server · Ressource und Darstellung
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #HTTP #backend
Erklärt wird das Anfrage-Antwort-Muster des Webs: Der Client fragt, der Server antwortet. Es passiert bei jedem Seitenaufruf, ob Browser, Smartphone-App oder Kommandozeile.
Zuerst tippt jemand eine Adresse ein, etwa eine mit Schema https, einem Host und dem Pfad zu einem Artikel. Der Browser zerlegt sie: Das Schema nennt die Art des Zugriffs, der Host den Zielrechner, der Pfad die Ressource. Der Browser ist hier der Client, also das Programm, das fragt. Das muss kein Browser sein; auch curl oder eine Mobile-App können diese Rolle übernehmen.
Dann baut der Client daraus eine HTTP-Anfrage, die Nachrichtenform des Webs. Sie besteht aus Methode, Ziel, Headern und optionalem Body. Die Methode sagt, was gewollt ist, etwa GET für reines Abfragen. Header sind kleine Zusatzinformationen.
Danach sendet der Client diese Anfrage an den Server, also das Programm, das antwortet. Der Server wartet nur; von sich aus schickt er nichts. Ohne vorherige Anfrage kommt keine Nachricht zurück. Die Begriffe Client und Server bezeichnen Rollen, keine Geräte. Wer fragt, bleibt in diesem Vorgang Client, auch wenn die Antwort aus Daten besteht.
Zuletzt antwortet der Server mit Statuscode, Headern und optionalem Body. Der Statuscode 200 meldet Erfolg, 404, dass der Server die Ressource unter diesem Pfad nicht findet. Die Antwort ist eine Darstellung der Ressource, etwa HTML für den Browser oder JSON-Daten für ein Programm. Da HTTP zustandslos ist, muss jede Anfrage alles nennen, was der Server zum Antworten braucht. Der Server weiß nie, was der Browser gerade anzeigt.
Wer denkt, Server könnten pushen, verwechselt Muster mit Ausnahmen.
📌 Anfrage-Antwort-Muster · Client und Server · Ressource und Darstellung
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #HTTP #backend
5 Tage vor
