Aufgabe 09 - API-Konsument

Aufgabe 09 - API-Konsument

Worum geht es?

Sie sprechen zum ersten Mal mit einem fremden Server: HTTP-Verkehr analysieren, eine öffentliche API anhand ihrer Dokumentation konsumieren und das Ganze robust gegen alles machen, was schiefgehen kann (siehe Kapitel HTTP und Schnittstellen).

Was Sie dafür brauchen

• Kapitel HTTP und Schnittstellen vollständig.
• Browser mit DevTools, Node.js/TypeScript, curl oder HTTPie.
• Eine öffentliche Test-API ohne Anmeldung (wird im Unterricht festgelegt). Drei bewährte Beispiele, mit denen Sie arbeiten können:
  • Open-Meteo (https://open-meteo.com) - Wetterdaten für beliebige Koordinaten, kein API-Schlüssel nötig.
  • REST Countries (https://restcountries.com) - Länderdaten wie Hauptstadt, Einwohnerzahl und Sprachen.
  • PokéAPI (https://pokeapi.co) - umfangreiche Daten zu Pokémon, gut zum Üben verschachtelter JSON-Strukturen.

Welche Kompetenzen Sie erwerben und zeigen

• Sie lesen HTTP-Verkehr im Netzwerk-Tab und stellen Anfragen von Hand.
• Sie konsumieren eine fremde API anhand ihrer Dokumentation mit fetch und typisieren den Datenvertrag.
• Sie behandeln alle drei Fehlerklassen der Netzwerkgrenze benutzergerecht.

Pädagogische Einordnung

• Reproduktion: HTTP-Bestandteile im Netzwerk-Tab identifizieren und benennen (Teil A).
• Reorganisation und Transfer: die API-Doku in Anfragen und typisierten Code übersetzen (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: Fehlerfälle systematisch provozieren, unterscheiden und die Robustheit nachweisen (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - HTTP beobachten

1. Öffnen Sie eine beliebige Webseite mit offenem Netzwerk-Tab (F12). Finden Sie: einen GET-Request, einen mit Status 200, einen mit 3xx oder 4xx.
2. Notieren Sie für einen Request: Methode, vollständige URL, drei Request-Header, Statuscode, Content-Type der Antwort.
3. Beantworten Sie in zwei Sätzen: Was unterscheidet 404 von 500, und wer hat jeweils den Fehler gemacht?

Teil B - Von Hand anfragen

1. Lesen Sie die Dokumentation der vereinbarten API: Welche Endpunkte gibt es, welche Parameter, wie sieht eine Antwort aus?
2. Stellen Sie zwei erfolgreiche Anfragen von Hand (Browser-Adresszeile, curl oder HTTPie) und sehen Sie sich die JSON-Antwort in Ruhe an.
3. Halten Sie den benötigten Ausschnitt der Antwort als TypeScript-Interface fest; nur die Felder, die Ihr Programm verwenden wird.

Teil C - Der typisierte Konsument

1. Schreiben Sie fetchJson<T>(url: string): Promise<T>: einen Wrapper, der bei !response.ok eine aussagekräftige Exception wirft (Statuscode und URL in der Meldung) und sonst das geparste JSON liefert.
2. Bauen Sie darauf ein kleines Konsolenprogramm: Es nimmt eine Eingabe (etwa einen Ortsnamen), fragt die API ab und zeigt ein aufbereitetes Ergebnis (“Villach: 18 °C, bewölkt”).
3. Nutzen Sie beim Zugriff auf optionale Felder ?. und ??; kein Absturz, wenn die API ein Feld weglässt.

Teil D - Expertenteil: Chaostest und Parallelabfrage

1. Chaostest: Ihr Programm muss drei Störungen unterscheidbar und verständlich melden (kein Stacktrace für Benutzer): (a) falsche Domain (Netzwerkfehler; fetch wirft), (b) existente Domain mit unbekanntem Endpunkt (404), (c) unsinnige Nutzereingabe (leeres Ergebnis oder Fehlermeldung der API). Führen Sie ein Protokoll: Störung, beobachtete Meldung, bestanden ja/nein.
2. Erweitern Sie das Programm: drei Eingaben auf einmal (etwa drei Orte), parallel abgefragt, mit Sammelbericht auch bei Teilausfällen. Das richtige Koordinationswerkzeug kennen Sie aus Aufgabe 07; begründen Sie die Wahl.
3. Ergänzen Sie ein Timeout von zwei Sekunden pro Anfrage über AbortController mit fetch-signal.
4. Beurteilen Sie in drei Sätzen: Welche der Störungen aus Punkt 1 kann Ihr Programm sinnvoll selbst behandeln, welche kann es nur sauber melden, und woran machen Sie den Unterschied fest?

Wissenscheck

1. Aus welchen Bestandteilen besteht ein HTTP-Request, aus welchen die Response?
2. Warum ist if (!response.ok) in jedem fetch-Aufruf Pflicht?
3. Welche drei Fehlerklassen hat jede Netzwerkgrenze?
4. Was gehört in ein Datenvertrags-Interface für eine fremde API, und was bewusst nicht?
5. Was bedeutet 429 Too Many Requests, und welche Übungsdisziplin verhindert es?

Abgabe

consumer.ts (Wrapper, Programm, Parallelfassung), das Interface des Datenvertrags, Ihre Notizen aus Teil A und das Chaostest-Protokoll.