Skip to content

Commit 657b5ba

Browse files
committed
Updated HTTP Exercise
1 parent 107f680 commit 657b5ba

1 file changed

Lines changed: 26 additions & 1 deletion

File tree

Material/Notes/Exercises/Exercise_2025-02-03_HTTP.md renamed to Material/Notes/Exercises/Exercise_2025-01-20_HTTP.md

Lines changed: 26 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
title: Übungsaufgabe HTTP
3-
date: 2025-02-03
3+
date: 2025-01-20
44
lang: de-DE
55
author: "Silas Schnurr"
66
...
@@ -60,6 +60,31 @@ Beschreiben Sie für jede Ressource:
6060

6161
Es reicht aus, vereinfachte Beispiel-Payloads anzugeben.
6262

63+
## Aufgabe 3
64+
65+
### HTTP als zustandsloses Protokoll
66+
67+
Erläutern Sie, was es bedeutet, dass HTTP ein zustandsloses Protokoll ist.
68+
Welche Vorteile ergeben sich daraus für die Skalierbarkeit von Webanwendungen und welche Probleme entstehen dadurch für typische Anwendungsfälle wie Authentifizierung?
69+
70+
### REST-Architekturstil
71+
72+
Beschreiben Sie ausführlich die grundlegenden Prinzipien des REST-Architekturstils.
73+
Gehen Sie dabei jeweils darauf ein, was jedes Prinzip bedeutet und warum es
74+
wichtig ist.
75+
76+
### Zustandsverwaltung in REST
77+
78+
Vergleichen Sie die drei im Skript beschriebenen Möglichkeiten zur Realisierung von Zustand in REST-Architekturen (Zustand im Client, Zustand im Server, Zustand als Ressource).
79+
Diskutieren Sie jeweils Vor- und Nachteile im Hinblick auf Fehlertoleranz und horizontale Skalierung.
80+
81+
### REST vs. Alternativen
82+
83+
Wählen Sie eine der vorgestellten REST-Alternativen (gRPC, GraphQL, WebSockets oder Server-Sent Events) und vergleichen Sie diese mit REST.
84+
Gehen Sie dabei auf typische Einsatzszenarien ein und begründen Sie, warum die gewählte Alternative dort besser geeignet ist als REST.
85+
86+
### Theoretische Fragen
87+
6388
## Information: Einordnung in die Softwareentwicklung
6489

6590
Diese Aufgabe ist Teil der Konzeptions- und Discovery-Phase der Softwareentwicklung und wird häufig als API-Design oder API-Konzeption bezeichnet. Ziel ist es, frühzeitig zu klären, welche Schnittstellen benötigt werden, bevor mit der eigentlichen Implementierung begonnen wird.

0 commit comments

Comments
 (0)