Praxis-Tutorial – HTTP und REST APIs für Entwickler

Einleitung

Das Internet basiert auf zahlreichen Technologien, von denen HTTP (Hypertext Transfer Protocol) eine der wichtigsten ist. In diesem Tutorial lernst du die Grundlagen von HTTP und REST (Representational State Transfer) kennen, um einen einfachen Einstieg in das Thema zu bekommen. Praxisnahe Beispiele helfen dir, das Verständnis zu vertiefen. Außerdem erfährst du mehr über wichtige Konzepte wie Authentifizierung, Sicherheitsaspekte und Caching.

1. Was ist HTTP?

HTTP (Hypertext Transfer Protocol) ist das grundlegende Kommunikationsprotokoll des Internets. Es ermöglicht den Austausch von Informationen zwischen einem Webbrowser (z. B. Google Chrome, Firefox oder Safari) und einem Webserver, auf dem Webseiten und andere Ressourcen gespeichert sind. Jedes Mal, wenn du eine URL in die Adressleiste deines Browsers eingibst oder auf einen Link klickst, wird eine HTTP-Anfrage an den Server gesendet, der daraufhin die angeforderte Webseite oder Ressource zurückliefert.

Ohne HTTP wäre das Surfen im Internet nicht möglich, da es als Vermittler zwischen dem Nutzer und dem Server fungiert. Es sorgt dafür, dass Texte, Bilder, Videos und andere Inhalte von einem Server geladen und korrekt im Browser angezeigt werden.

1.1 HTTP-Methoden – Wie kommunizieren Browser und Server?

HTTP bietet verschiedene Methoden, mit denen ein Client (z. B. ein Browser) mit einem Server kommunizieren kann. Jede dieser Methoden hat einen speziellen Zweck:

  • GET – Ruft Daten von einem Server ab. Dies ist die häufigste Methode und wird zum Laden von Webseiten verwendet.
    Beispiel: Wenn du auf eine Nachrichtenseite gehst, sendet dein Browser eine GET-Anfrage an den Server, um die Artikel und Bilder anzuzeigen.

  • POST – Sendet Daten an den Server.
    Beispiel: Wenn du ein Kontaktformular ausfüllst und abschickst, werden die eingegebenen Informationen per POST-Anfrage an den Server gesendet.

  • PUT – Aktualisiert eine bestehende Ressource auf dem Server.
    Beispiel: Eine App, mit der du dein Profilbild ändern kannst, würde eine PUT-Anfrage verwenden, um das neue Bild hochzuladen und das alte zu ersetzen.

  • DELETE – Löscht eine Ressource auf dem Server.
    Beispiel: In einer Webanwendung zum Verwalten von Aufgaben kann eine DELETE-Anfrage verwendet werden, um eine Aufgabe endgültig zu entfernen.

  • PATCH – Aktualisiert eine Ressource teilweise.
    Beispiel: Eine Social-Media-Plattform könnte PATCH nutzen, um nur den Status-Text eines Beitrags zu ändern, anstatt den gesamten Beitrag neu zu speichern.

  • HEAD – Ruft nur die Header-Informationen einer Ressource ab, nicht aber den eigentlichen Inhalt.
    Beispiel: Suchmaschinen verwenden HEAD-Anfragen, um zu prüfen, ob eine Webseite existiert und wann sie zuletzt aktualisiert wurde, ohne den gesamten Inhalt zu laden.

  • OPTIONS – Gibt an, welche Methoden auf einem Server unterstützt werden.
    Beispiel: Ein Entwickler könnte eine OPTIONS-Anfrage stellen, um herauszufinden, ob ein Server die PUT- oder DELETE-Methode akzeptiert.

1.2 HTTP-Statuscodes – Welche Antworten gibt der Server?

Jede HTTP-Anfrage führt zu einer Antwort des Servers, die durch sogenannte Statuscodes beschrieben wird. Diese Codes zeigen an, ob eine Anfrage erfolgreich war oder ob ein Problem aufgetreten ist.

Erfolgreiche Antworten (2xx):

HTTP StatusBedeutungBeispiel

200 OK

Die Anfrage war erfolgreich und die gewünschte Ressource wird zurückgeliefert.

Eine Webseite wird fehlerfrei geladen.

201 Created

Eine neue Ressource wurde erfolgreich erstellt.

Beim Registrieren auf einer Website wird dein Nutzerkonto im System angelegt.

204 No Content

Die Anfrage war erfolgreich, aber es gibt keine Inhalte zum Zurücksenden.

Wenn du eine Einstellung speicherst, aber keine neue Seite geladen werden muss.

Client-Fehler (4xx):

HTTP StatusBedeutungBeispiel

400 Bad Request

Die Anfrage war fehlerhaft, oft wegen falscher Syntax oder ungültiger Eingaben.

Beim Absenden eines Formulars wurden Pflichtfelder nicht ausgefüllt.

401 Unauthorized

Zugriff verweigert, da keine gültige Authentifizierung vorliegt.

Eine geschützte Seite erfordert eine Anmeldung, die nicht erfolgt ist.

403 Forbidden

Der Zugriff auf die Ressource ist untersagt.

Eine interne Firmenwebseite ist nur für Mitarbeiter zugänglich.

404 Not Found

Die angeforderte Seite oder Datei wurde nicht gefunden.

Ein Nutzer klickt auf einen alten Link, der nicht mehr existiert.

Server-Fehler (5xx):

HTTP StatusBedeutungBeispiel

500 Internal Server Error

Ein allgemeiner Fehler auf dem Server.

Ein technisches Problem in der Webanwendung führt dazu, dass die Seite nicht geladen wird.

502 Bad Gateway

Der Server hat eine ungültige Antwort von einem anderen Server erhalten.

Wenn ein Webserver mit einem Backend-Dienst kommuniziert und dieser nicht reagiert.

503 Service Unavailable

Der Server ist vorübergehend nicht verfügbar, oft wegen Wartungsarbeiten.

Ein Online-Shop ist während eines großen Updates nicht erreichbar.

Diese Statuscodes sind essenziell für Entwickler und Nutzer, da sie helfen, Fehler zu identifizieren und Probleme schnell zu lösen.

1.3. Wichtige HTTP-Header für Sicherheit, Caching und Authentifizierung

HTTP-Header sind ein wesentlicher Bestandteil der Kommunikation zwischen Client (z. B. Browser) und Server. Sie enthalten zusätzliche Metadaten zur Anfrage oder Antwort und beeinflussen das Verhalten von Webseiten, APIs und Anwendungen.

Ohne HTTP-Header könnten viele moderne Webanwendungen nicht funktionieren, da sie beispielsweise für die Authentifizierung, das Caching und die Datenverarbeitung erforderlich sind. Sie werden in jeder HTTP-Anfrage und -Antwort verwendet, um dem Server oder Client mitzuteilen, wie mit den gesendeten oder empfangenen Daten umzugehen ist.

Hier sind einige der wichtigsten HTTP-Header mit anschaulichen Beispielen.

1. Content-Type – Welches Datenformat wird gesendet oder erwartet?

Der Content-Type-Header gibt an, in welchem Format die Daten übermittelt werden. Dies ist entscheidend für Webbrowser, APIs und Server, um die richtige Interpretation und Verarbeitung der Daten sicherzustellen.

Beispiel für eine JSON-Antwort:

Content-Type: application/json

Wird verwendet, wenn eine API eine Antwort im JSON-Format zurückliefert, z. B. bei der Kommunikation zwischen einer Web-App und einem Server.

Beispiel für eine HTML-Seite:

Content-Type: text/html

Signalisiert, dass der Server eine Webseite im HTML-Format sendet.

Beispiel für eine Bilddatei:

Content-Type: image/png

Wird gesetzt, wenn ein Server eine PNG-Bilddatei ausliefert, z. B. für ein Logo oder eine Produktabbildung.

2. Authorization – Authentifizierung für geschützte Bereiche

Der Authorization-Header wird verwendet, um Zugriff auf geschützte Ressourcen zu erhalten, z. B. eine API oder eine interne Unternehmensseite. Ohne eine gültige Authentifizierung verweigert der Server den Zugriff mit dem Statuscode 401 Unauthorized.

Beispiel für einen Token-basierten Zugriff (häufig bei modernen APIs):

Authorization: Bearer <token>

Wird oft in Web-Apps verwendet, um sich gegenüber einem Server zu authentifizieren, z. B. für eine geschützte Benutzerkonto-Seite oder einen API-Request mit OAuth 2.0.

Beispiel für eine Basic-Authentifizierung (einfache Benutzername-Passwort-Kombination):

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Hier wird der Benutzername und das Passwort als Base64-kodierte Zeichenkette übertragen. Diese Methode wird oft in älteren Systemen genutzt, ist aber weniger sicher als Token-basierte Verfahren.

3. Cache-Control – Wie sollen Inhalte zwischengespeichert werden?

Der Cache-Control-Header bestimmt, wie lange eine Ressource im Cache des Browsers oder eines Proxys gespeichert werden darf. Dies verbessert die Ladezeiten und reduziert die Serverlast, indem bereits geladene Inhalte nicht erneut heruntergeladen werden müssen.

Beispiel für eine Seite, die nicht zwischengespeichert werden soll:

Cache-Control: no-cache, no-store, must-revalidate

Wird z. B. für sensible Daten verwendet, wie Online-Banking-Seiten oder private Dashboards, um sicherzustellen, dass stets aktuelle Inhalte geladen werden.

Beispiel für eine Ressource, die für eine Woche gecacht werden darf:

Cache-Control: max-age=604800

Nützlich für statische Inhalte wie Logos oder Schriftarten, die sich selten ändern und schnell aus dem Cache geladen werden können.

Beispiel für eine gecachte Seite, die regelmäßig neu validiert wird:

Cache-Control: public, must-revalidate

Wird z. B. für Nachrichtenartikel oder Produktseiten verwendet, die sich gelegentlich ändern, aber möglichst schnell geladen werden sollen.

HTTP-Header sind eine entscheidende Grundlage für den modernen Datenaustausch im Internet. Sie steuern nicht nur, wie Inhalte übertragen werden, sondern auch, wie sicher und effizient sie verarbeitet werden.

2. Was ist REST?

REST (Representational State Transfer) ist ein Architekturstil für Webdienste, der auf dem Hypertext Transfer Protocol (HTTP) basiert. REST wurde entwickelt, um eine einfache, skalierbare und flexible Kommunikation zwischen verteilten Systemen zu ermöglichen. Durch seine intuitive Struktur ist REST die Grundlage vieler moderner Web-APIs, darunter die Schnittstellen von Social-Media-Plattformen, E-Commerce-Websites und Cloud-Diensten.

2.1. REST-Prinzipien

REST folgt mehreren essenziellen Prinzipien, die eine effiziente und standardisierte Kommunikation gewährleisten.

Client-Server-Modell

REST basiert auf einer klaren Trennung zwischen Client und Server. Der Client sendet Anfragen (Requests), während der Server darauf mit Antworten (Responses) reagiert. Diese Trennung ermöglicht eine bessere Skalierbarkeit und Flexibilität. Beispielsweise kann ein Webbrowser (Client) über eine REST-API mit einem Onlineshop-Server kommunizieren, um Produktdaten abzurufen oder Bestellungen aufzugeben.

Stateless (Zustandslosigkeit)

Jede Anfrage an den Server enthält alle notwendigen Informationen zur Verarbeitung. Der Server speichert keinen Sitzungsstatus zwischen Anfragen, was zu einer einfacheren Skalierbarkeit führt.

Ein Beispiel: Ein mobiles Banking-App-Client sendet eine REST-Anfrage, um den Kontostand abzurufen:

GET /konto/123456 HTTP/1.1
Host: api.bank.com

Da jede Anfrage unabhängig ist, enthält sie bereits die vollständige Identifikation des Kundenkontos (z. B. 123456).

Ressourcenbasiertes Design

Alle Daten und Funktionen in einer REST-API werden als Ressourcen betrachtet. Jede Ressource hat eine eindeutige URL, die ihre Identität beschreibt. So kann beispielsweise ein Benutzer in einem System über folgende URL abgerufen werden:

GET /users/1 HTTP/1.1
Host: api.example.com

Hier repräsentiert /users/1 den Benutzer mit der ID 1. Die API gibt dann die entsprechenden Benutzerdaten zurück.

Verwendung standardisierter HTTP-Methoden

REST setzt auf gängige HTTP-Methoden für die wichtigsten CRUD-Operationen (Create, Read, Update, Delete):

Create (Erstellen) → POST

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Anna",
  "email": "anna@example.com"
}

Dies erstellt einen neuen Benutzer mit dem Namen Anna.

Read (Lesen) → GET

GET /users/1 HTTP/1.1
Host: api.example.com

Hier wird der Benutzer mit der ID 1 abgerufen.

Update (Aktualisieren) → PUT oder PATCH

PUT /users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Anna",
  "email": "anna@example.com"
}

Dies aktualisiert die Benutzerdaten von Ana zu Anna.

Delete (Löschen) → DELETE

DELETE /users/1 HTTP/1.1
Host: api.example.com

Hier wird der Benutzer mit der ID 1 aus dem System gelöscht.

Repräsentationen von Ressourcen

Daten in REST können in verschiedenen Formaten zurückgegeben werden. Häufig werden JSON (JavaScript Object Notation) und XML (Extensible Markup Language) verwendet, aber auch HTML kann eine Option sein.

Beispiel JSON:

{
  "id": 1,
  "name": "Max",
  "email": "max@example.com"
}

Dieses Format ist leicht verständlich und wird von modernen Webanwendungen bevorzugt.

Beispiel XML:

<user>
  <id>1</id>
  <name>Max</name>
  <email>max@example.com</email>
</user>

XML wird oft in älteren Systemen oder SOAP-Webdiensten verwendet.

Beispiel HTML:

<div>
  <h1>Max</h1>
  <p>Email: max@example.com</p>
</div>

Dieses Format eignet sich für direkte Einbettungen in Webseiten.

2.2. Beispiel einer REST-API

Eine REST-API bietet standardisierte Schnittstellen für den Zugriff auf Ressourcen. Diese Schnittstellen ermöglichen es Entwicklern, effizient mit einer Anwendung zu kommunizieren, indem sie HTTP-Methoden nutzen.

Beispiel: Abruf von Benutzerdaten

Ein Client kann mit einer GET-Anfrage die Daten eines Benutzers abrufen:

GET https://api.example.com/users/1

Die API antwortet mit den gespeicherten Benutzerdaten:

{
  "id": 1,
  "name": "Max",
  "email": "max@example.com"
}

Dieses Beispiel zeigt, wie einfach es ist, Daten aus einer REST-API abzurufen.

Beispiel: Erstellen eines neuen Benutzers

Möchte ein Client einen neuen Benutzer hinzufügen, sendet er eine POST-Anfrage mit den entsprechenden Daten:

POST https://api.example.com/users
Content-Type: application/json

{
  "name": "Anna",
  "email": "anna@example.com"
}

Die API speichert den neuen Benutzer und gibt eine Bestätigung zurück:

{
  "id": 2,
  "name": "Anna",
  "email": "anna@example.com"
}

Hier sieht man, wie einfach neue Daten über eine REST-API angelegt werden können. Dieses Prinzip findet Anwendung in vielen Bereichen, beispielsweise bei der Registrierung neuer Nutzer auf Social-Media-Plattformen oder in Online-Shops.

2.3. Authentifizierung und Sicherheit

Die Sicherheit von REST-APIs ist ein zentraler Aspekt bei der Entwicklung und Nutzung von Webservices. Verschiedene Authentifizierungsmechanismen gewährleisten, dass nur berechtigte Benutzer und Systeme auf sensible Daten zugreifen können. Nachfolgend werden einige der gängigsten Methoden erläutert:

API-Schlüssel (API Key)

API-Schlüssel sind eine der einfachsten Methoden zur Authentifizierung. Dabei erhält der Client einen eindeutigen Schlüssel, der mit jeder Anfrage übermittelt werden muss. Diese Methode eignet sich gut für einfache Anwendungsfälle wie das Abrufen öffentlicher Daten oder die Identifikation eines Nutzers.

Beispiel: Ein Client sendet eine Anfrage mit einem API-Schlüssel als Authentifizierungs-Token:

GET /data HTTP/1.1
Host: api.example.com
Authorization: ApiKey 123456789abcdef

Basic Authentication

Die Basic Authentication ist eine einfache Methode, bei der Benutzername und Passwort in der Anfrage als Base64-kodierter String übertragen werden. Diese Methode sollte nur in Kombination mit HTTPS verwendet werden, um die sensiblen Zugangsdaten vor Angreifern zu schützen.

Beispiel: Eine Anfrage mit Basic Authentication könnte folgendermaßen aussehen:

GET /protected-resource HTTP/1.1
Host: api.example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Es gibt auch fortgeschrittenere Authentifizierungsmechanismen wie OAuth und JWT (JSON Web Token), die eine sicherere und flexiblere Methode zur Autorisierung bieten.

Zusammenfassung

In diesem Tutorial hast du die Grundlagen von HTTP und REST kennengelernt, um dein Verständnis für diese essenziellen Technologien zu erweitern.

Zunächst wurde HTTP als Kommunikationsprotokoll des Internets erklärt, einschließlich der verschiedenen HTTP-Methoden (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) und deren Bedeutung. Anschließend wurden HTTP-Statuscodes detailliert beschrieben, damit du die unterschiedlichen Serverantworten besser verstehst. Zudem hast du wichtige HTTP-Header kennengelernt, die eine zentrale Rolle in den Bereichen Sicherheit, Caching und Authentifizierung spielen.

Im zweiten Abschnitt hast du REST (Representational State Transfer) als Architekturstil für Webdienste kennengelernt, der auf HTTP basiert. Die zentralen REST-Prinzipien, darunter das Client-Server-Modell, Statelessness, ressourcenbasierte Strukturen und die Nutzung standardisierter HTTP-Methoden, wurden ausführlich erläutert. Zudem hast du verschiedene API-Beispiele für CRUD-Operationen (Create, Read, Update, Delete) gesehen.

Abschließend wurde die Bedeutung der Authentifizierung und Sicherheit in REST-APIs thematisiert. Du hast verschiedene Methoden wie API-Schlüssel, Basic Authentication und fortgeschrittene Ansätze wie OAuth und JWT kennengelernt.

Durch dieses Tutorial hast du ein solides Grundverständnis für HTTP und REST erhalten und kannst dieses Wissen nutzen, um sichere und effiziente RESTful-Webservices zu entwickeln.