Webentwicklung · Anwendungsentwicklung
HTTP und REST: Grundlagen und Aufgaben
Verstehe Methoden, Statuscodes und Ressourcen einer HTTP-API. Übe passende Anfragen, Fehlerantworten und die Bedeutung von sicher und idempotent.
Verantwortlich: Bär Softwareentwicklung UG (haftungsbeschränkt) / Aktualisiert: 07.10.2026
Automatisch bewertetes Thementraining
Wissen direkt in einem kurzen Set prüfen
Bearbeite bis zu 5 zufällig ausgewählte Aufgaben in etwa 5 Minuten. Du erhältst nach jeder Aufgabe Feedback und am Ende eine kompakte Auswertung.
Ressourcen und HTTP-Nachrichten
Eine API adressiert Ressourcen etwa über /tickets/42. Eine Anfrage enthält Methode, Ziel, Header und gegebenenfalls einen Body; die Antwort enthält Status, Header und eventuell Nutzdaten.
REST beschreibt einen Architekturstil. JSON über HTTP allein erfüllt ihn nicht automatisch. Zustandslose Kommunikation bedeutet, dass jede Anfrage die benötigten Informationen enthält; gespeicherte Ressourcen in einer Datenbank bleiben möglich.
- Accept: gewünschtes Antwortformat
- Content-Type: Format des gesendeten Bodys
- Authentifizierung und Berechtigung pro Anfrage prüfen
Sichere und idempotente Methoden
GET dient dem Abrufen und ist nach HTTP-Semantik sicher: Der Client fordert keine Zustandsänderung an. Protokollierung kann trotzdem stattfinden. POST verarbeitet Daten gemäß der Zielressource, beispielsweise zum Anlegen.
Idempotent heißt: Mehrere identische Anfragen haben dieselbe beabsichtigte Wirkung wie eine. PUT und DELETE sind idempotent; die Antworten müssen bei Wiederholung nicht gleich sein. PATCH ist nicht generell idempotent.
- GET: abrufen, sicher und idempotent
- PUT: Zielzustand an einer bekannten URI setzen
- DELETE: Zuordnung der Ressource entfernen
Statuscodes und fehlgeschlagene Anfragen
200 steht für Erfolg mit üblicher Antwort, 201 für eine erfolgreiche Erstellung und 204 für Erfolg ohne Antwortinhalt. 400 kennzeichnet einen fehlerhaften Request, 401 fehlende oder ungültige Authentifizierung und 403 eine verweigerte Aktion.
404 steht für eine nicht gefundene Ressource, 409 für einen Konflikt mit dem aktuellen Zustand. 500 bezeichnet einen unerwarteten Serverfehler. Wiederhole schreibende Anfragen nach einem Timeout nur mit einem passenden Wiederholungs- beziehungsweise Idempotenzkonzept.
- 401 ist nicht dasselbe wie 403
- 201 kann die Ressourcenadresse im Location-Header nennen
- Ein Timeout beweist nicht, dass eine Erstellung ausgeblieben ist
Durchgerechnetes Beispiel
Ein Ticket anlegen
POST /tickets sendet einen gültigen neuen Ticketinhalt. Die API erstellt Ticket 42.
- 01 Der Server prüft Authentifizierung, Berechtigung und Eingaben.
- 02 Nach erfolgreicher Erstellung antwortet er mit 201 Created.
- 03 Location: /tickets/42 nennt die neue Ressource.
Ergebnis / Ein nachfolgendes GET /tickets/42 kann das Ticket abrufen.
Durchgerechnetes Beispiel
Eine Löschung wiederholen
DELETE /tickets/42 entfernt das Ticket; die identische Anfrage wird erneut gesendet.
- 01 Die erste erfolgreiche Anfrage kann 204 liefern.
- 02 Die zweite Anfrage kann je nach API-Vertrag 404 oder erneut 204 liefern.
- 03 Nach beiden Anfragen bleibt die beabsichtigte Wirkung dieselbe: Das Ticket ist entfernt.
Ergebnis / DELETE bleibt idempotent, auch wenn die Statuscodes verschieden sind.
Jetzt in etwa 5 Minuten selbst anwenden
| Methode | Sicher | Idempotent |
|---|---|---|
| GET | Ja | Ja |
| POST | Nein | Nicht garantiert |
| PUT | Nein | Ja |
| DELETE | Nein | Ja |
| PATCH | Nein | Nicht garantiert |
Typische Fehler vermeiden
- Idempotent bedeutet nicht, dass jede Antwort identisch ist.
- Eine Zustandsänderung wie „Ticket löschen“ gehört nicht in GET.
- HTTPS ersetzt keine Prüfung der Objektberechtigung.
Direkt anwenden
8 Übungen mit Lösungen
Beantworte die Aufgabe zuerst selbst. Öffne danach die Lösung, um Antwort und Rechenweg zu vergleichen.
-
Anwendungsentwicklung
Welche HTTP-Methode ist für das reine Abrufen von Ticket 42 vorgesehen?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: GET /tickets/42
GET fordert eine Darstellung an und ist nach HTTP-Semantik sicher und idempotent.
-
Anwendungsentwicklung
Eine API hat nach POST /tickets erfolgreich ein neues Ticket erzeugt. Welcher Statuscode drückt die Erstellung aus? Gib nur die Zahl ein.
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: 201
201 Created kennzeichnet eine erfolgreiche Erstellung; ein Location-Header kann die URI nennen.
-
Anwendungsentwicklung
Ein gültig angemeldeter Nutzer darf ein fremdes Projekt nicht lesen. Welcher Statuscode beschreibt die verweigerte Aktion direkt, wenn die Existenz der Ressource nicht verborgen werden soll?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: 403
403 steht für eine verweigerte Aktion. 401 betrifft fehlende beziehungsweise ungültige Authentifizierung.
-
Anwendungsentwicklung
Welche Aussage über idempotente HTTP-Methoden ist richtig?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: Mehrere identische Anfragen haben dieselbe beabsichtigte Wirkung wie eine
Idempotenz betrifft die beabsichtigte Wirkung, nicht identische Antworten.
-
Anwendungsentwicklung
DELETE /tickets/42 liefert zunächst 204 und bei Wiederholung 404. Welche Bewertung ist richtig?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: Das ist mit der Idempotenz von DELETE vereinbar
Die Ressource bleibt entfernt; unterschiedliche Antworten ändern die beabsichtigte Wirkung nicht.
-
Anwendungsentwicklung
Ordne die HTTP-Header ihrer Aufgabe zu.
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: Accept → Gewünschtes Antwortformat; Content-Type → Format des übermittelten Inhalts; Location → Adresse etwa einer neu erstellten Ressource
Accept beschreibt die gewünschten Antwortmedien, Content-Type die gesendete Darstellung und Location eine Ziel- beziehungsweise Ressourcenadresse.
-
Anwendungsentwicklung
Ein POST zum Anlegen einer Bestellung endet beim Client mit einem Timeout. Welche Aussage ist richtig?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: Die Bestellung kann bereits erstellt worden sein; eine Wiederholung benötigt ein passendes Idempotenzkonzept
Die Verarbeitung auf dem Server und der Empfang der Antwort können auseinanderfallen. Eine blinde Wiederholung kann eine zweite Bestellung erzeugen.
-
Anwendungsentwicklung
Welche Antwort ist mit 204 No Content vereinbar?
Übungsvorschau: Notiere hier zuerst deinen Ansatz oder starte dieselbe Aufgabe anschließend im bewerteten Lernmodus.
Lösung anzeigen Lösung ausblenden
Musterlösung: Eine Erfolgsantwort ohne Antwortinhalt
204 bedeutet Erfolg ohne Inhalt; für einen Antwortbody ist ein anderer passender Status zu verwenden.
Kurz erklärt
Häufige Fragen
Ist jede JSON-API eine REST-API?
Nein. REST umfasst weitere Architekturbedingungen wie Zustandslosigkeit und eine einheitliche Schnittstelle.
Darf eine 204-Antwort JSON enthalten?
Nein. 204 bezeichnet eine Antwort ohne Inhalt. Nutze bei einem Antwortbody einen geeigneten anderen Erfolgsstatus.
Fachliche Referenz: HTTP Working Group: HTTP-Semantik. Die Erklärungen und Aufgaben auf dieser Seite sind eigenständig formuliert.
Weiterlernen