Das HTTP-Protokoll (Hypertext Transfer Protocol) ist ein weit verbreitetes Kommunikationsprotokoll, das für den Austausch von Daten zwischen Webbrowsern und Webservern verwendet wird. Es ermöglicht den Abruf von Ressourcen wie HTML-Dokumenten, Bildern, Videos und anderen Dateien über das Internet. In diesem Artikel werden wir das HTTP-Protokoll detailliert untersuchen, seine Funktionen, Struktur und die wichtigsten Konzepte erläutern.
Das HTTP-Protokoll bildet die Grundlage für den Datenaustausch im World Wide Web und ermöglicht den Zugriff auf Ressourcen wie Webseiten, Bilder und Dateien. Es ist wichtig, die grundlegenden Konzepte und Funktionen von HTTP zu verstehen, um effektiv mit Webanwendungen und APIs zu arbeiten.
HTTP ist ein zustandsloses, textbasiertes Protokoll, das auf dem Client-Server-Modell basiert. Es wurde entwickelt, um den Abruf von Ressourcen über das World Wide Web (WWW) zu ermöglichen. Ein Client (z. B. ein Webbrowser) sendet eine Anfrage an einen Server, der dann eine entsprechende Antwort zurückgibt. Die Kommunikation erfolgt über das TCP/IP-Protokoll.
Eine HTTP-Verbindung besteht aus einer Client-Anfrage und einer Serverantwort. Der Client initiiert die Verbindung und sendet eine Anfrage an den Server. Der Server verarbeitet die Anfrage und sendet eine entsprechende Antwort zurück an den Client. Nach Abschluss der Übertragung wird die Verbindung normalerweise geschlossen, es sei denn, es wird die Keep-Alive-Funktion verwendet, um eine persistentere Verbindung aufrechtzuerhalten.
HTTP definiert verschiedene Anfragemethoden (auch als HTTP-Verben bezeichnet), die den beabsichtigten Zweck der Anfrage angeben. Hier sind einige häufig verwendete HTTP-Anfragemethoden:
HTTP-Responses enthalten Statuscodes, die den Status der Anfrage anzeigen. Hier sind einige gängige HTTP-Statuscodes:
Es gibt viele weitere Statuscodes, die spezifische Bedeutungen haben und je nach Situation verwendet werden können. Diese Liste enthält jedoch einige der häufigsten Statuscodes, die in HTTP-Responses verwendet werden. Die vollständige Liste der Statuscodes und ihre Bedeutung finden Sie in der offiziellen HTTP-Spezifikation.
HTTP-Requests und -Responses enthalten Header-Felder, die zusätzliche Informationen über die Anfrage oder Antwort enthalten. Header-Felder sind in der Form “Feldname: Feldwert” aufgebaut. Sie können Informationen wie den Host, den Inhaltstyp, die Codierung, Cookies und vieles mehr enthalten. Header-Felder ermöglichen es den Clients und Servern, zusätzliche Kontextinformationen zu übermitteln und die Kommunikation anzupassen.
Accept: Gibt an, welche Medientypen der Client
akzeptieren kann. Beispiel:
Accept: application/json
Content-Type: Gibt den Medientyp des Inhalts der
Anfrage an. Beispiel:
Content-Type: application/json
Authorization: Enthält die
Authentifizierungsinformationen für den Zugriff auf die Ressource.
Beispiel:
Authorization: Bearer <access_token>
User-Agent: Identifiziert den Client oder die
Software, die die Anfrage sendet. Beispiel:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36
Cache-Control: Steuert das Caching-Verhalten des
Servers oder Clients. Beispiel:
Cache-Control: max-age=3600
If-None-Match: Wird verwendet, um eine Bedingung
anzugeben, dass die Antwort nur gesendet werden soll, wenn die
angegebene ETag-Übereinstimmung nicht vorliegt. Beispiel:
If-None-Match: "abc123"
Hier ist eine Liste einiger gängiger oder häufig verwendeter Request Header in HTTP-Anfragen:
Es gibt noch viele weitere Header, die in HTTP-Anfragen verwendet werden können, je nach den Anforderungen der Anwendung und dem Kontext der Kommunikation. Jeder Header hat seine eigene Funktion und Bedeutung in der HTTP-Kommunikation.
Content-Type: Gibt den Medientyp des Inhalts der
Antwort an. Beispiel:
Content-Type: application/json
Authorization: Falls erforderlich, enthält
dieser Header Informationen zur Authentifizierung oder Autorisierung des
Clients. Beispiel:
Authorization: Bearer <access_token>
Cache-Control: Steuert das Caching-Verhalten des
Clients oder Proxy-Servers für die Antwort. Beispiel:
Cache-Control: max-age=3600
ETag: Identifiziert eine eindeutige Version der
Antwort, die für die spätere Verwendung im Cache oder bei bedingten
Anfragen verwendet werden kann. Beispiel:
ETag: "abc123"
Location: Wird bei einer Umleitung verwendet, um
die neue URL anzugeben, zu der der Client weitergeleitet werden soll.
Beispiel: Location: https://example.com/new-page
Set-Cookie: Wird verwendet, um dem Client ein
Cookie zu setzen oder zu aktualisieren. Beispiel:
Set-Cookie: sessionId=abc123; Expires=Wed, 21 May 2023 12:00:00 GMT; Secure; HttpOnly
Hier ist eine Liste einiger gängiger oder häufig verwendeter Response Header in HTTP-Antworten:
Es gibt viele weitere Response Header, die je nach Anwendungsfall und Serverkonfiguration verwendet werden können. Jeder Header hat eine spezifische Bedeutung und dient dazu, dem Client Informationen über die Antwort zu liefern und das Verhalten des Clients oder Proxys zu steuern.
Query-Parameter werden in der URL einer HTTP-Anfrage verwendet und
dienen dazu, zusätzliche Informationen an den Server zu übermitteln. Sie
werden nach einem Fragezeichen (?) an die URL angehängt und
mit dem Ampersand-Zeichen (&) getrennt. Jeder
Query-Parameter besteht aus einem Schlüssel-Wert-Paar, wobei der
Schlüssel und der Wert durch ein Gleichheitszeichen (=)
verbunden sind.
Ein Beispiel für eine URL mit Query-Parametern könnte so aussehen:
https://api.example.com/search?query=books&category=fictionIn diesem Beispiel sind query und category
die Schlüssel der Query-Parameter, während books und
fiction ihre entsprechenden Werte sind. Diese Parameter
können verwendet werden, um eine Suche nach Büchern in der Kategorie
“Fiction” durchzuführen.
Query-Parameter sind optional und können in beliebiger Reihenfolge angegeben werden. Sie werden häufig verwendet, um Filter, Sortierungen oder Pagination in einer API anzugeben.
Pfadparameter werden in der URL einer HTTP-Anfrage verwendet und
dienen dazu, Variablen in der URL selbst darzustellen. Sie sind Teil des
Pfades und werden durch spezielle Platzhalter in der URL markiert. In
der Regel werden sie in geschweiften Klammern ({})
eingeschlossen.
Ein Beispiel für eine URL mit Pfadparametern könnte so aussehen:
https://api.example.com/users/{userId}In diesem Beispiel ist {userId} der Pfadparameter, der
den Platzhalter für die Benutzer-ID darstellt. Dies ermöglicht es,
dynamisch auf bestimmte Benutzer in der API zuzugreifen, indem man die
entsprechende Benutzer-ID in den Pfad einfügt.
Ein weiteres Beispiel könnte wie folgt aussehen:
https://api.example.com/categories/{categoryId}/products/{productId}In diesem Fall sind sowohl {categoryId} als auch
{productId} Pfadparameter, die verwendet werden, um auf
bestimmte Kategorien und Produkte in der API zuzugreifen.
Pfadparameter sind Teil der URL-Struktur und dienen dazu, spezifische Ressourcen oder Aktionen innerhalb einer API zu identifizieren.
Zusammenfassend kann man sagen, dass Query-Parameter zusätzliche Informationen in der URL einer HTTP-Anfrage übermitteln und optional sind, während Pfadparameter Variablen in der URL selbst darstellen und Teil des Pfads sind. Query-Parameter werden für optionale Filter, Sortierungen oder Pagination verwendet, während Pfadparameter spezifische Ressourcen oder Aktionen in der API identifizieren. Beide Arten von Parametern spielen eine wichtige Rolle in der Kommunikation zwischen Client und Server bei der Verwendung von HTTP-Anfragen.
Cookies sind kleine Textdateien, die vom Server an den Client gesendet und auf dem Client gespeichert werden. Sie dienen dazu, Informationen über den Benutzer und den Sitzungszustand beizubehalten. Cookies können verwendet werden, um Daten zwischen aufeinanderfolgenden Anfragen auszutauschen und den Benutzer zu authentifizieren.
Hier sind einige Beispiele für die Verwendung von Cookies in HTTP-Anfragen und -Antworten:
Wenn ein Client eine HTTP-Anfrage an einen Server sendet, kann er
Cookies im Cookie-Header mitliefern. Hier ist ein
Beispiel:
GET /api/products HTTP/1.1
Host: example.com
Cookie: sessionId=abc123; userId=12345In diesem Beispiel enthält der Cookie-Header zwei
Cookies: sessionId mit dem Wert abc123 und
userId mit dem Wert 12345. Der Server kann
diese Informationen verwenden, um den Benutzer zu authentifizieren oder
seinen Zustand zu überprüfen.
Ein Server kann Cookies in der HTTP-Antwort setzen, indem er den
Set-Cookie-Header verwendet. Hier ist ein Beispiel:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionId=abc123; Expires=Wed, 21 May 2023 12:00:00 GMT; Secure; HttpOnly
Set-Cookie: userId=12345; Max-Age=3600; Path=/In diesem Beispiel setzt der Server zwei Cookies. Das erste Cookie
sessionId hat den Wert abc123 und ist mit
einem Ablaufdatum versehen. Es ist als sicheres Cookie markiert, was
bedeutet, dass es nur über eine verschlüsselte Verbindung gesendet wird,
und es ist als HttpOnly markiert, was bedeutet, dass es nicht über
JavaScript zugänglich ist. Das zweite Cookie userId hat den
Wert 12345 und eine maximale Gültigkeitsdauer von 3600
Sekunden (1 Stunde). Es gilt für alle Pfade auf der Domain.
Der Client speichert die Cookies und sendet sie in nachfolgenden
Anfragen an den Server, indem er den Cookie-Header
verwendet.
Um ein Cookie zu löschen, kann der Server es in der HTTP-Antwort mit einem Ablaufdatum in der Vergangenheit setzen. Hier ist ein Beispiel:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionId=; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Max-Age=0; Path=/In diesem Beispiel wird das Cookie sessionId durch
Setzen eines Ablaufdatums in der Vergangenheit gelöscht. Der Client
entfernt dann das Cookie aus seinem Speicher.
Es gibt noch viele weitere Optionen und Attribute, die beim Setzen von Cookies verwendet werden können, wie Domain, Secure, SameSite usw. Die genaue Verwendung hängt von den Anforderungen und dem Verhalten Ihrer Anwendung ab.
HTTPS (HTTP Secure) ist eine verschlüsselte Version des HTTP-Protokolls, bei dem die Daten zwischen Client und Server mithilfe von SSL (Secure Sockets Layer) oder dem neueren TLS (Transport Layer Security) verschlüsselt werden. HTTPS bietet eine sichere Kommunikation und schützt die Integrität und Vertraulichkeit der übertragenen Daten.
Das HTTP-Protokoll bildet das grundlegende Kommunikationsmittel des World Wide Web. Es ermöglicht die Übertragung von Ressourcen zwischen Webbrowsern und Webservern. Durch das Verständnis der HTTP-Grundlagen, wie Anfragemethoden, Statuscodes, Header-Felder und Cookies, können Entwickler effektiv mit Web-APIs arbeiten und die Leistung und Sicherheit ihrer Webanwendungen verbessern.
In HTTP-Anfragen können Informationen auf verschiedene Weisen übermittelt werden, darunter durch Request Header und Request Parameter. Beide haben ihre spezifischen Anwendungen und Verwendungszwecke.
Ein Request Header ist ein Teil der HTTP-Anfrage, der zusätzliche
Informationen über die Anfrage oder den Client enthält. Beispiele für
typische Header sind Accept, der den vom Client
akzeptierten Medientyp angibt, Content-Type, der den
Medientyp der Körperdaten angibt, und Authorization, der
Authentifizierungsinformationen enthält.
Header können auch benutzerdefinierte Informationen enthalten, die für eine bestimmte Anwendung spezifisch sind. Allerdings werden diese Informationen in der Regel verwendet, um den Kontext oder das Verhalten der Anfrage zu steuern und werden nicht als Teil der eigentlichen Geschäftslogik der Anwendung betrachtet.
Request Parameter sind Informationen, die in der URL der HTTP-Anfrage übertragen werden. Es gibt zwei Arten von Parametern:
Path Parameter: Sie sind Teil der URL selbst.
Zum Beispiel könnte in der URL
https://api.example.com/users/123 der Wert 123
ein Pfadparameter sein, der die Benutzer-ID angibt.
Query Parameter: Sie werden am Ende der URL nach
einem ? angefügt und mit & getrennt. Zum
Beispiel könnte in der URL
https://api.example.com/users?name=John der Wert
John ein Query-Parameter sein, der den Namen des zu
suchenden Benutzers angibt.
Im Allgemeinen werden Parameter dazu verwendet, die Geschäftslogik der Anwendung zu steuern. Sie können zum Beispiel dazu verwendet werden, um zu bestimmen, welche Ressource angefordert wird oder um die Ressourcen zu filtern oder zu sortieren, die von der API zurückgegeben werden.
Die Syntax für einen HTTP Request in Backus-Naur Form (BNF) kann wie folgt aussehen:
<http-request> ::= <request-line>
<headers>
<CRLF>
[ <message-body> ]
<request-line> ::= <method> SP <request-target> SP <http-version> CRLF
<method> ::= "GET" | "POST" | "PUT" | "DELETE" | ...
<request-target> ::= <absolute-path> [ "?" <query> ]
<absolute-path> ::= "/" <segment> [ "/" <segment> ]*
<segment> ::= <pchar>*
<pchar> ::= <unreserved> | <pct-encoded> | ":" | "@" | "&" | "=" | "+" | "$" | ","
<unreserved> ::= ALPHA | DIGIT | "-" | "." | "_" | "~"
<pct-encoded> ::= "%" HEXDIG HEXDIG
<query> ::= <pchar> [ <query> ]
<http-version> ::= "HTTP" "/" 1*DIGIT "." 1*DIGIT
<headers> ::= <header> [ <CRLF> <header> ]*
<header> ::= <field-name> ":" SP <field-value>
<field-name> ::= <token>
<field-value> ::= *( <field-content> | <obs-fold> )
<field-content> ::= <field-vchar> | <obs-text>
<field-vchar> ::= <VCHAR> | <obs-text>
<VCHAR> ::= %x21-7E
<obs-text> ::= %x80-FF
<obs-fold> ::= <CRLF> SP
<message-body> ::= <body-content>
<body-content> ::= <octet> | <body-content> <octet>
<octet> ::= %x00-FF
<SP> ::= SPACE
<CRLF> ::= CR LFBitte beachten Sie, dass dies eine vereinfachte Darstellung der BNF-Syntax ist und nicht alle Aspekte eines vollständigen HTTP-Anfrages abdeckt. Es dient nur zur Veranschaulichung der allgemeinen Struktur eines HTTP Requests in BNF-Form.
Hier ist eine vereinfachte Version der BNF-Syntax für einen HTTP-Response:
<http-response> ::= <status-line>
<headers>
<CRLF>
[ <message-body> ]
<status-line> ::= <http-version> SP <status-code> SP <reason-phrase> CRLF
<http-version> ::= "HTTP" "/" 1*DIGIT "." 1*DIGIT
<status-code> ::= 3DIGIT
<reason-phrase> ::= <token>
<headers> ::= <header> [ <CRLF> <header> ]*
<header> ::= <field-name> ":" SP <field-value>
<field-name> ::= <token>
<field-value> ::= *( <field-content> | <obs-fold> )
<field-content> ::= <field-vchar> | <obs-text>
<field-vchar> ::= <VCHAR> | <obs-text>
<VCHAR> ::= %x21-7E
<obs-text> ::= %x80-FF
<message-body> ::= <body-content>
<body-content> ::= <octet> | <body-content> <octet>
<octet> ::= %x00-FF
<SP> ::= SPACE
<CRLF> ::= CR LFBeachten Sie, dass dies ebenfalls eine vereinfachte Darstellung der BNF-Syntax für einen HTTP-Response ist und nicht alle Aspekte eines vollständigen HTTP-Responses abdeckt. Die tatsächliche Syntax kann je nach Version des HTTP-Protokolls und anderen Faktoren variieren. Diese BNF dient nur zur Veranschaulichung der allgemeinen Struktur eines HTTP-Responses.
Hier ist ein Beispiel für einen HTTP-Request und den dazu passenden HTTP-Response:
HTTP-Request:
GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36
Accept: application/jsonHTTP-Response:
HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 01 Apr 2021 12:34:56 GMT
Server: Apache/2.4.38 (Ubuntu)
Content-Length: 120
{
"users": [
{
"id": 1,
"name": "John Doe",
"email": "johndoe@example.com"
},
{
"id": 2,
"name": "Jane Smith",
"email": "janesmith@example.com"
}
]
}Im obigen Beispiel ist der Request ein GET-Request an den Pfad “/api/users” auf dem Server “example.com”. Es werden auch einige Header-Felder wie “User-Agent” und “Accept” angegeben.
Der Response ist ein 200-OK-Response mit dem Inhaltstyp “application/json”. Es wird ein JSON-Objekt zurückgegeben, das eine Liste von Benutzerdaten enthält. Der Response-Body enthält die Details von zwei Benutzern, einschließlich ihrer IDs, Namen und E-Mail-Adressen.
Bitte beachten Sie, dass dies nur ein Beispiel ist und die tatsächlichen Requests und Responses je nach API und Server variieren können.
Die offizielle Spezifikation für das HTTP-Protokoll wird vom World Wide Web Consortium (W3C) und der Internet Engineering Task Force (IETF) entwickelt und gepflegt. Es gibt verschiedene Versionen des HTTP-Protokolls, wobei HTTP/1.1 und HTTP/2 die am weitesten verbreiteten Versionen sind.
Hier sind die Links zu den offiziellen Spezifikationen:
Die Spezifikationen enthalten detaillierte Informationen zur Struktur des Protokolls, den unterstützten Anfragemethoden, den Statuscodes, den Header-Feldern, der Cookie-Spezifikation, der Verbindungskontrolle und vielen anderen Aspekten des HTTP-Protokolls.
Bitte beachten Sie, dass die Spezifikationen technische Dokumente sind und einige Kenntnisse über Protokolle und Netzwerkkommunikation erfordern, um vollständig verstanden zu werden.