LearnReally
by learnreallyin GermanCurated

Available inGermanEnglishFrenchHindiPortugueseRussianSpanish

HTTP und REST für Backend-Interviews

Erkläre, warum ein Statuscode, ein Header oder ein Cookie-Flag sich genau so verhält, und lies einen kaputten Request-Response-Austausch bis zur Fehlerursache zurück. Für Backend-Entwickler, die schon REST-APIs ausgeliefert haben, sie aber nie laut erklären mussten. Achtundachtzig Karten folgen einem einzigen Request: die Nachricht, Methoden, Statuscodes, Caching, Cookies und CORS, REST-Trade-offs, HTTP/2 und 3 sowie Login-Token; Schwachstellenklassen gehören zum OWASP-Deck.

88cards1imports
Try it first
Contents

Card 1 of 88

Slot B ist das eine Header-Feld, das jeder HTTP/1.1-Request tragen muss. Nenn es und sag, was es leistet.

Host. Es benennt die Autorität, an die der Request geht, und darum kann eine Adresse viele Sites bedienen.

Hints

Das Request-Target lässt die Autorität weg, also muss sie woanders stehen.

Source

RFC 9110 §7.2: Ein Client MUSS in HTTP/1.1 ein Host-Feld senden, ein Server MUSS einen Request ohne Host mit 400 abweisen. Virtual Hosting gibt es allein wegen dieses Feldes. HTTP/2 und HTTP/3 ersetzen es durch das Pseudo-Feld :authority mit demselben Inhalt. Zur Sprache dieses Kurses: Es heißt hier durchweg Header, Request und Response. „Kopfzeile“ und „Anfrage“ stehen in keinem Log, in keinem RFC und in keinem Interview, und gefragt ist immer das Wort von der Leitung.