Schnittstellen & Datenaustausch
Datenquellen verstehen, CSV und JSON prüfen, HTTP-Schnittstellen benutzen und Daten sicher zusammenführen.
Vom Kundenauftrag zum Datenvertrag
Kläre zuerst, welches System welche Daten benötigt, wem die Daten gehören und wie aktuell sie sein müssen. Dokumentiere Feldnamen, Datentypen, Pflichtfelder, Einheiten, Zeichencodierung, erlaubte Werte und eine stabile Identität. Eine technisch gültige Datei kann fachlich unbrauchbar sein: 20 ohne Einheit ist keine eindeutige Temperatur. Lege fest, was bei fehlenden Feldern, unbekannten Statuswerten und widersprüchlichen Datensätzen passieren soll.
Ticket: id = positive Ganzzahl; titel = nicht leer; status = offen | erledigt; optional: bearbeiter_id; Export: UTF-8.
CSV korrekt einlesen
CSV ist tabellarischer Text. Vereinbare Trennzeichen, Kopfzeile, UTF-8 und Behandlung leerer Werte. Ein Trennzeichen innerhalb eines Feldes erfordert Anführungszeichen; ein Anführungszeichen im eingeschlossenen Feld wird verdoppelt. Zeilenumbrüche können ebenfalls innerhalb eines eingeschlossenen Feldes vorkommen. split(";") genügt deshalb nicht als allgemeiner Parser. CSV liefert zunächst Texte: IDs, Zahlen und Wahrheitswerte müssen kontrolliert konvertiert werden.
id;titel;status 7;"Drucker; Empfang";offen 8;"Monitor ""links""";erledigt
JSON, XML und Zeichencodierung
JSON beschreibt Objekte, Arrays, Zeichenketten, Zahlen, Wahrheitswerte und null. Objektschlüssel und Texte stehen in doppelten Anführungszeichen; Kommentare und nachgestellte Kommas gehören nicht zum JSON-Standard. Die Reihenfolge der Objektschlüssel ist normalerweise kein fachliches Sortierkriterium, die Reihenfolge einer Liste dagegen schon. XML verwendet Elemente und Attribute und benötigt einen passend abgesicherten Parser: Externe Entitäten dürfen nicht ungeprüft aufgelöst werden. UTF-8 und korrekte Content-Type-Angaben vermeiden fehlerhafte Umlaute.
{"id":7,"titel":"Drucker prüfen","status":"offen","bearbeiter_id":null}HTTP-Anfragen und Ressourcen
Eine HTTP-Anfrage besteht aus Methode, Ziel, Headern und gegebenenfalls einem Body. GET liest eine Repräsentation, POST verarbeitet eine neue Eingabe, PUT ersetzt den Zustand einer Zielressource und PATCH beschreibt eine Teiländerung. DELETE entfernt die Zuordnung zur Ressource. Idempotent heißt: Wiederholung hat die gleiche beabsichtigte Wirkung, nicht zwingend die gleiche Antwort. Benutze GET nicht für Änderungen. HTTPS schützt den Transport, ersetzt aber weder Eingabeprüfung noch Berechtigungen.
GET /tickets/7
Accept: application/json
POST /tickets
Content-Type: application/json
{"titel":"Drucker prüfen"}Statuscodes richtig auswerten
200 meldet eine erfolgreiche Antwort; 201 wird etwa für eine neu angelegte Ressource verwendet und kann mit Location deren Adresse nennen. 204 enthält keinen Antwortinhalt: JSON.parse auf einem leeren Body ist falsch. 400 weist auf eine fehlerhafte Anfrage hin, 401 auf fehlende oder ungültige Authentifizierung, 403 auf verweigerten Zugriff, 404 auf eine nicht gefundene Ressource, 409 auf einen Konflikt und 429 auf eine Begrenzung. Bei 5xx liegt ein Serverfehler vor. Der Client prüft Status und Medientyp, bevor er Daten weiterverarbeitet.
Authentifizierung, Autorisierung und CORS
Authentifizierung klärt, wer anfragt; Autorisierung, ob diese Person genau diesen Datensatz lesen oder ändern darf. Ein angemeldeter Benutzer darf nicht automatisch fremde Tickets sehen. Tokens gehören nicht in öffentliches Frontend-Markup oder Logdateien. CORS ist eine Browserregel zum Lesen fremder Origins und kein Ersatz für Zugriffskontrolle. Cookiebasierte Schreibzugriffe benötigen Schutz gegen CSRF. Serverseitige HTTP-Clients brauchen zusätzlich Regeln gegen SSRF, etwa das ungeprüfte Abrufen interner Adressen.
Validieren und kontrolliert umformen
Prüfe Struktur und fachliche Regeln vor der Speicherung. Eine ID muss beispielsweise eine positive ganze Zahl sein; "12abc" ist keine gültige ID. Unterscheide fehlend, null, leere Zeichenkette und 0. Benenne Felder über ein dokumentiertes Mapping um und übersetze Statuswerte nur anhand einer festgelegten Tabelle. Lege Grenzen für Dateigröße, Zeilenzahl und Verschachtelung fest. Weise fehlerhafte Zeilen nachvollziehbar zurück, statt sie stillschweigend zu reparieren. Eine Fehlermeldung nennt Zeile oder Feld, aber keine geheimen Zugangsdaten.
Daten zusammenführen und Dubletten behandeln
Nutze eine fachlich stabile ID statt eines Namens als Join-Schlüssel. Zwei Personen können gleich heißen. Identische Wiederholungen dürfen bei entsprechender Regel zusammengefasst werden; widersprüchliche Daten zur gleichen ID brauchen dagegen eine definierte Konfliktentscheidung. Bei einer Importwiederholung verhindert ein eindeutiger Schlüssel oder ein Upsert doppelte Datensätze. Eine Transaktion verhindert teilweise bestätigte zusammengehörige Änderungen. Dokumentiere, ob unbekannte Fremdschlüssel den Import stoppen oder in einer Fehlerliste landen.
Pagination, Wiederholungen und Parallelität
APIs liefern größere Datenmengen oft in Seiten. Folge dem dokumentierten Cursor oder nächsten Link und prüfe auf Wiederholungen; die Zahl der Datensätze auf Seite eins ist nicht automatisch die Gesamtzahl. Bei gleichzeitigen Änderungen kann Offset-Pagination Einträge überspringen oder doppelt liefern. Ein Timeout beweist nicht, dass eine Schreiboperation fehlgeschlagen ist. Wiederhole nicht-idempotente POST-Anfragen nur mit einer geeigneten serverseitigen Idempotenzregel. Beachte Retry-After und begrenze Wiederholungen mit Wartezeit und Zufallsanteil.
Zeit, Datenschutz und Nachvollziehbarkeit
Übertrage Zeitpunkte mit Zeitzoneninformation, etwa 2026-10-05T14:30:00Z. Lokale Uhrzeiten ohne Offset sind bei Zeitumstellungen mehrdeutig. Datumsangaben ohne Uhrzeit können dagegen bewusst ein reines Kalenderdatum darstellen. Übertrage nur notwendige personenbezogene Felder und vereinbare Löschfristen und Zugriffsrechte. Protokolliere Korrelations-ID, Zeitpunkt und Ergebnis, ohne vollständige Tokens oder unnötige Personenprofile mitzuschreiben. Prüfe die rechtlichen Bedingungen der konkreten Datenquelle.
Schnittstellen testen und versionieren
Ein guter Vertragstest prüft gültige Eingaben, fehlende Pflichtfelder, falsche Datentypen, unbekannte IDs, verweigerte Zugriffe und leere Ergebnisse. Teste Sonderzeichen, Dubletten, mehrere Seiten und Abbrüche. Eine neue Pflichtspalte kann bestehende Clients brechen; plane Änderungen, Übergangszeit und Versionsstrategie. Nutze ein kontrolliertes Übungssystem statt fremder produktiver APIs. Erfolg bedeutet nicht nur HTTP 200: Das Ergebnis muss auch den vereinbarten fachlichen Regeln entsprechen.
Praxisauftrag: Supportdaten importieren
Ein Dienstleister liefert Tickets als CSV. Erstelle zuerst den Datenvertrag, prüfe die Datei und wandle sie in ein JSON-Array um. Weise ungültige IDs und unbekannte Statuswerte zurück. Führe anschließend Ticket- und Benutzerquelle über die Benutzer-ID zusammen; lasse fehlende Beziehungen sichtbar. Teste einen erneuten Import und dokumentiere Fehlerzahlen, Datenschutzannahmen und Abnahmekriterien. Die Datenaustausch-Werkstatt unterstützt die konkreten Parser-, Validierungs- und Mapping-Schritte.