Übungsaufgaben zu JSON

Übungsaufgaben zu JSON

https://bildung.social/@oerinformatik/

https://oer-informatik.de/json-uebungsaufgaben

JSON, Datentypen, Syntaxfehler, ISO 8601, Escape-Sequenz, JSONPath, JSON Schema, Validierung, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 59 min, mehrere Aufgaben): Drei Übungsaufgaben zur JavaScript Object Notation. Zum Einstieg bestimmst Du in der Konfiguration eines E-Ink-Türschilds Bausteine und Datentypen, erkennst gültiges JSON und liest Werte über Pfade aus. Danach notierst Du eine Aktivität der Let’s-Meet-App als JSON-Dokument, maskierst Sonderzeichen, begründest ISO 8601 für Datumsangaben und analysierst ein Dokument, das ein Parser einliest, das aber trotzdem Fehler enthält. Zum Schluss prüfst Du Tracker-Profile mit einem JSON Schema, ergänzt das Schema und beurteilst, was eine Schema-Prüfung leisten kann. Alle Beispiellösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Diese Übungsaufgaben gehören zum Artikel JSON: Syntax, Datentypen und Prüfung. Den Vergleich von JSON mit CSV und XML übst Du in den Übungsaufgaben zu Datenaustauschformaten, JSON in Dokumentendatenbanken in den Übungsaufgaben zu NoSQL und Dokumentendatenbanken.

Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1. Als FIA, FISY, FIDP, FIDV, ISE oder IKD musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das ist Aufgabe 2.1. Von FIA und IKD wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1) keine Probleme bereiten. Achte auf die Operatoren: „Nennen“ und „Angeben“ verlangen Stichworte, „beschreiben“ und „erläutern“ verlangen ganze Sätze mit Begründung oder Beispiel, „prüfen“ verlangt ein Urteil mit Begründung. Schreib JSON so, dass ein Parser es fehlerfrei einlesen könnte. Schreib Deine Lösung zuerst vollständig auf, bevor Du die Beispiellösung aufklappst.

Aufgabe 1.1: Die Konfiguration der E-Ink-Türschilder (Basiskompetenz)

(ca. 17 min Bearbeitungszeit)

Für das Barcamp „Lernen.Digital.Leben 2027“ am Ratz und Rübe Berufskolleg baut das Technikteam um Emre Aksoy zwölf E-Ink-Türschilder auf. Jedes Türschild lädt beim Start eine Konfigurationsdatei vom Info-Server. Für Raum A104 sieht sie so aus:

{
  "geraet": "TS-A104",
  "raum": "A104",
  "vlan": 120,
  "mqttBroker": "10.140.0.5",
  "anzeige": { "breitePx": 800, "hoehePx": 480, "farbig": false },
  "aktualisierungMin": 5,
  "slots": ["10:00", "11:00", "12:45", "13:45", "14:45"],
  "notiz": null
}

a) Nenne die beiden Strukturen, aus denen JSON-Dokumente aufgebaut sind, und gib zu jeder ein Beispiel aus der Konfigurationsdatei an. (4 Punkte)

Je Struktur 1 Punkt für die Nennung, 1 Punkt für das Beispiel:

  • Objekt in geschweiften Klammern mit Schlüssel-Wert-Paaren, z. B. das ganze Dokument oder "anzeige": { "breitePx": 800, "hoehePx": 480, "farbig": false }.

  • Array in eckigen Klammern mit einer geordneten Liste von Werten, z. B. "slots": ["10:00", "11:00", "12:45", "13:45", "14:45"].

b) Bestimme für die folgenden Felder den JSON-Datentyp. (6 Punkte)

Feld JSON-Datentyp
geraet
vlan
mqttBroker
anzeige
farbig (in anzeige)
notiz

Je richtiger Zeile 1 Punkt:

Feld JSON-Datentyp
geraet Zeichenkette (string)
vlan Zahl (number)
mqttBroker Zeichenkette (string) – eine IP-Adresse ist keine Zahl, sie hat mehrere Punkte
anzeige Objekt (object)
farbig Wahrheitswert (boolean)
notiz Nullwert (null)

c) Emre testet verschiedene Zeilen mit einem JSON-Parser. Gib für jede Zeile an, ob sie gültiges JSON ist. (6 Punkte)

Nr. Zeile gültiges JSON (ja/nein)
1 {"raum": "A104"}
2 {'raum': 'A104'}
3 {"farbig": False}
4 {"slots": ["10:00", "11:00",]}
5 {"vlan": "120"}
6 []

Je richtiger Angabe 1 Punkt:

Nr. gültig Begründung
1 ja Schlüssel und Zeichenkette in doppelten Anführungszeichen
2 nein einfache Anführungszeichen sind nicht erlaubt
3 nein Wahrheitswerte werden klein geschrieben: false
4 nein Komma nach dem letzten Array-Element
5 ja gültig, aber "120" ist eine Zeichenkette, keine Zahl
6 ja ein leeres Array ist ein vollständiges JSON-Dokument

d) Das Türschild liest einzelne Werte über ihren Pfad aus. Gib die Werte an, die es unter anzeige.hoehePx und unter slots[2] findet. (2 Punkte)

Je Wert 1 Punkt:

  • anzeige.hoehePx → 480

  • slots[2] → "12:45" – der Index beginnt bei 0, slots[2] ist also das dritte Element.

Aufgabe 2.1: Aktivitäten über die REST-API der Let’s-Meet-App (Kernkompetenz)

(ca. 20 min Bearbeitungszeit)

Die Let’s Meet GmbH in Bielefeld baut das Backend ihrer Freizeit-App neu auf. Die Apps holen die Aktivitäten über eine REST-API unter https://api.letsmeet.example/v1, die JSON-Dokumente liefert. Dein Mit-Azubi Jonas Weber soll die Antwort des Endpunkts /v1/aktivitaeten/{id} festlegen; Entwicklungsleiter Yusuf Demir hat ihm diese Angaben gegeben:

  • Aktivität 31 hat den Titel Brettspielabend: kooperative Spiele.

  • Sie beginnt am 5. Februar 2027 um 19:00 Uhr und endet um 21:30 Uhr (Ortszeit Bielefeld, Winterzeit, UTC+1).

  • Das Mindestalter ist 16, es dürfen höchstens 6 Personen teilnehmen, der Kostenbeitrag beträgt 2,50 €.

  • Treffpunkt ist das Café am Siegfriedplatz; er ist barrierefrei.

  • Angemeldet sind die Nutzenden mit den IDs 3, 13 und 9; die Warteliste ist leer.

  • Eine Notiz der Organisatorin gibt es nicht.

a) Notiere die Antwort als JSON-Dokument. Wähle passende Schlüssel und Datentypen; der Treffpunkt soll ein eingebettetes Objekt sein. (9 Punkte)

{
  "id": 31,
  "titel": "Brettspielabend: kooperative Spiele",
  "beginn": "2027-02-05T19:00:00+01:00",
  "ende": "2027-02-05T21:30:00+01:00",
  "mindestalter": 16,
  "maxTeilnehmende": 6,
  "kostenbeitragEuro": 2.5,
  "treffpunkt": {
    "name": "Café am Siegfriedplatz",
    "barrierefrei": true
  },
  "teilnehmende": [3, 13, 9],
  "warteliste": [],
  "notiz": null
}

Bewertung (9 Punkte):

  • äußeres Objekt korrekt geklammert, alle Schlüssel in doppelten Anführungszeichen, Kommas richtig (1 Punkt),

  • id, mindestalter, maxTeilnehmende als Zahl ohne Anführungszeichen (1 Punkt), kostenbeitragEuro mit Dezimalpunkt (2.5 oder 2.50) (1 Punkt),

  • beginn und ende als Zeichenkette nach ISO 8601 mit Zeitzonenabstand (2 Punkte; ohne Zeitzonenabstand 1 Punkt),

  • treffpunkt als eingebettetes Objekt mit barrierefrei als Wahrheitswert (2 Punkte),

  • teilnehmende als Array von Zahlen, warteliste als leeres Array (1 Punkt),

  • notiz mit null (oder weggelassen) (1 Punkt).

Andere sinnvolle Schlüsselnamen sind richtig. Statt ende ist auch eine Dauer möglich, z. B. "dauerMin": 150.

b) Im Excel-Export des früheren Dienstleisters stehen Termine als 05.02.27 19:00. Erläutere zwei Gründe, warum die API stattdessen eine Zeichenkette nach ISO 8601 mit Zeitzonenabstand liefern sollte. (4 Punkte)

Je Grund 2 Punkte (Grund 1 Punkt, Erläuterung 1 Punkt), z. B.:

  • Eindeutigkeit: 05.02.27 kann der 5. Februar oder (in US-Schreibweise) der 2. Mai sein, und das Jahrhundert fehlt. 2027-02-05 lässt keine zweite Deutung zu.

  • Zeitzone: Ohne Zeitzonenabstand weiß eine App nicht, ob 19:00 Uhr Ortszeit oder UTC gemeint ist; spätestens bei der Zeitumstellung oder bei Nutzenden auf Reisen werden Termine um eine Stunde falsch angezeigt.

  • Einlesen ohne Sonderlogik: JSON hat keinen Datumstyp. ISO 8601 lesen die Datumsbibliotheken aller gängigen Sprachen direkt ein (z. B. Java OffsetDateTime), ein eigenes Format müsste jede App selbst zerlegen.

  • Sortierbarkeit: ISO-8601-Zeichenketten gleicher Form lassen sich als Text richtig sortieren.

c) Die Aktivität 32 hat einen zweizeiligen Titel. In der ersten Zeile steht Quiz "Bielefeld gibt's nicht", in der zweiten Treffpunkt am Eingang. Notiere das Schlüssel-Wert-Paar titel mit diesem Wert in gültigem JSON. (3 Punkte)

{ "titel": "Quiz \"Bielefeld gibt's nicht\"\nTreffpunkt am Eingang" }

Bewertung: doppelte Anführungszeichen mit \" maskiert (1 Punkt), Zeilenumbruch als \n (1 Punkt), Apostroph unverändert und Paar sonst korrekt (1 Punkt). Ein maskierter Apostroph \' ist in JSON nicht erlaubt (0,5 Punkte Abzug).

d) Jonas findet im Protokoll des Backends die folgende Antwort. Der JSON-Parser der App liest sie ohne Fehlermeldung ein, trotzdem zeigt die App Unsinn an.

{
  "id": 8,
  "titel": "Kochabend mit Weinbegleitung",
  "mindestalter": "18",
  "maxTeilnehmende": 10,
  "teilnehmende": [1, 4, 6],
  "barrierefrei": "nein",
  "teilnehmende": [1, 4, 6, 12]
}

Beschreibe drei Probleme dieses Dokuments und ihre Folgen. (6 Punkte)

Je Problem 2 Punkte (Problem 1 Punkt, Folge 1 Punkt):

  • Doppelter Schlüssel teilnehmende: RFC 8259 legt nicht fest, welcher Wert gilt. Je nach Parser zeigt die App drei oder vier Teilnehmende – oder ein anderer Parser bricht mit einem Fehler ab. Der Fehler fällt nur auf, wenn verschiedene Programme das Dokument lesen.

  • "mindestalter": "18" als Zeichenkette: Ein Vergleich wie „Alter ≥ Mindestalter“ vergleicht dann Text mit Zahl oder Text mit Text ("9" > "18" ist als Text wahr). Im schlimmsten Fall sehen Minderjährige eine Aktivität ab 18, die sie nicht sehen dürften.

  • "barrierefrei": "nein" als Zeichenkette: Jede nicht leere Zeichenkette gilt in vielen Sprachen als „wahr“; der Filter „barrierefreier Treffpunkt“ würde diese Aktivität anzeigen. Richtig ist false.

Hinweis: barrierefrei gehört eigentlich zum Treffpunkt (eingebettetes Objekt wie in Teilaufgabe a); auch diese Antwort ist als drittes Problem richtig, wenn sie begründet ist.

Aufgabe 3.1: Tracker-Profile mit JSON Schema prüfen (Profilkompetenz)

(ca. 22 min Bearbeitungszeit)

Die CSB-Rad GmbH in Bielefeld startet am 1. April 2027 den Ortungsdienst „CSB-Rad Connect Privat“ mit dem Tracker RadTrack 868. Weitere Tracker-Modelle sollen folgen, unter anderem ein Fahrtenschreiber mit LTE-M. Für jedes Modell lädt der Hersteller ein Profil als JSON-Dokument auf die Plattform; das Backend konfiguriert damit die Geräte. Damit fehlerhafte Profile gar nicht erst gespeichert werden, hat Geschäftsführer Cem Sarıkaya dieses JSON Schema festgelegt:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Trackerprofil",
  "type": "object",
  "properties": {
    "modell": { "type": "string", "minLength": 3 },
    "hersteller": { "type": "string" },
    "intervallSek": { "type": "integer", "minimum": 10, "maximum": 3600 },
    "akkuWarnungProzent": { "type": "integer", "minimum": 5, "maximum": 50 },
    "funk": {
      "type": "array",
      "items": { "type": "string", "enum": ["LoRaWAN", "NB-IoT", "LTE-M", "Bluetooth"] },
      "minItems": 1
    },
    "geofence": {
      "type": "object",
      "properties": {
        "radiusM": { "type": "number", "exclusiveMinimum": 0 },
        "aktiv": { "type": "boolean" }
      },
      "required": ["radiusM", "aktiv"]
    }
  },
  "required": ["modell", "hersteller", "intervallSek", "funk"]
}

a) Dein Mit-Azubi Jonas fragt, wozu das Schema gut ist, wenn der JSON-Parser doch ohnehin Fehler meldet. Erläutere den Unterschied zwischen der Prüfung durch einen JSON-Parser und der Prüfung gegen ein JSON Schema und nenne einen Nutzen des Schemas für CSB-Rad. (4 Punkte)

  • Der Parser prüft nur die Syntax: Klammern, Anführungszeichen, Kommas, Schreibweise der Literale. Ein syntaktisch gültiges Profil kann trotzdem Felder vermissen lassen oder falsche Datentypen enthalten (1 Punkt).

  • Das Schema prüft Struktur und Inhalt: welche Felder Pflicht sind (required), welchen Datentyp sie haben (type) und welche Werte erlaubt sind (minimum, enum, minItems …) (2 Punkte).

  • Nutzen (1 Punkt), z. B.: Fehlerhafte Profile verschiedener Hersteller werden automatisch und mit genauer Fehlermeldung abgewiesen, bevor sie Tracker falsch konfigurieren (z. B. ein Sendeintervall von 5 s, das den Akku leert); das Schema dient zugleich als eindeutige Schnittstellenbeschreibung für die Hersteller.

b) Prüfe, ob die drei folgenden Profile zum Schema gültig sind. Gib bei ungültigen Profilen alle Verstöße an. (9 Punkte)

Profil 1:

{
  "modell": "RadTrack 868",
  "hersteller": "Ostwestfalen Ortung GmbH",
  "intervallSek": 900,
  "funk": ["LoRaWAN", "Bluetooth"],
  "geofence": { "radiusM": 150, "aktiv": true }
}

Profil 2:

{
  "modell": "FS-LTE 2",
  "hersteller": "Lipper Funktechnik",
  "intervallSek": "30",
  "funk": ["LTE"]
}

Profil 3:

{
  "modell": "RadTrack 868",
  "hersteller": "Ostwestfalen Ortung GmbH",
  "intervallSek": 5,
  "akkuWarnungProzent": 20,
  "funk": [],
  "geofence": { "aktiv": false }
}

Je Profil 3 Punkte:

  • Profil 1: gültig (3 Punkte). Alle Pflichtfelder sind vorhanden, 900 liegt zwischen 10 und 3600, beide Funktechniken stehen in der enum-Liste, und geofence enthält radiusM (größer als 0) und aktiv. Dass akkuWarnungProzent fehlt, ist erlaubt.

  • Profil 2: ungültig (Urteil 1 Punkt, je Verstoß 1 Punkt):

    • "intervallSek": "30" ist eine Zeichenkette, verlangt ist integer.
    • "LTE" steht nicht in der enum-Liste (gemeint ist vermutlich "LTE-M").

  • Profil 3: ungültig (je Verstoß 1 Punkt; das Urteil ergibt sich aus den Verstößen):

    • "intervallSek": 5 liegt unter dem minimum 10.
    • "funk": [] hat weniger als ein Element (minItems: 1).
    • In geofence fehlt das Pflichtfeld radiusM.

c) Cem möchte das Schema verschärfen: Künftig muss jedes Profil die Firmware-Version als Zeichenkette im Feld firmware enthalten, und Felder, die im Schema nicht beschrieben sind, sollen abgelehnt werden. Gib die nötigen Änderungen am Schema an. (4 Punkte)

Je Änderung 1 Punkt:

  1. unter properties ein neues Feld "firmware": { "type": "string" } (optional mit "minLength": 1 oder einem pattern wie "^[0-9]+\\.[0-9]+\\.[0-9]+$"),

  2. "firmware" in die Liste required aufnehmen,

  3. "additionalProperties": false auf oberster Ebene ergänzen,

  4. für eingebettete Objekte gilt das nicht automatisch: "additionalProperties": false zusätzlich im Objekt geofence, wenn auch dort keine unbekannten Felder erlaubt sein sollen.

Ausschnitt des geänderten Schemas:

{
  "type": "object",
  "properties": {
    "firmware": { "type": "string", "minLength": 1 }
  },
  "required": ["modell", "hersteller", "intervallSek", "funk", "firmware"],
  "additionalProperties": false
}

(Die übrigen Einträge unter properties bleiben unverändert und sind hier weggelassen.)

d) Bastian Ludwig aus der Werkstatt meint: „Wenn ein Profil gegen das Schema gültig ist, dann stimmen die Daten auch.“ Nimm Stellung zu dieser Aussage. (3 Punkte)

Die Aussage ist so nicht richtig (1 Punkt). Begründung (2 Punkte, je Argument 1 Punkt), z. B.:

  • Das Schema prüft nur Struktur, Datentypen und Wertebereiche, nicht die fachliche Richtigkeit: Ein Profil mit "modell": "RadTrack 868" und "funk": ["LTE-M"] ist gültig, obwohl der RadTrack 868 per LoRaWAN funkt.

  • Zusammenhänge zwischen Feldern prüft das Schema in dieser Form nicht, z. B. ob ein kurzes Sendeintervall zur Akkukapazität passt oder ob ein Hersteller überhaupt freigeschaltet ist.

  • Ist das Schema selbst lückenhaft (fehlendes required, fehlendes additionalProperties), rutschen auch unvollständige oder überzählige Angaben durch.

Eine andere, schlüssig begründete Stellungnahme ist ebenfalls richtig.

e) Das Backend liest aus gültigen Profilen den Geofence-Radius und die zweite angegebene Funktechnik. Gib die beiden JSONPath-Ausdrücke an und nenne die Werte für Profil 1. (4 Punkte)

Je Ausdruck 1 Punkt, je Wert 1 Punkt:

  • $.geofence.radiusM → 150

  • $.funk[1] → "Bluetooth" (der Index beginnt bei 0)

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu JSON” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/json-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/datenformate/xml. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...