Spezifikation / Library-APIJSON2.1

Jakarta JSON Processing

JSON-P ist die Low-Level-API für JSON Parsing, Streaming, Transformation und Generierung.

Einordnung

Spezifikation / Library-API

Enterprise-Rolle

Sie ist sinnvoll, wenn genaue Kontrolle über JSON-Struktur, Streaming oder dynamische Dokumente erforderlich ist.

Fachliches Verständnis

Sie ist sinnvoll, wenn genaue Kontrolle über JSON-Struktur, Streaming oder dynamische Dokumente erforderlich ist. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Kernkonzepte

JsonObject/JsonArray.
Streaming Parser und Generator.
JsonPointer und JsonPatch.

Typische Einsatzfälle

Große JSON-Dokumente streamen.
API-Gateway Payloads transformieren.
JSON Patch verarbeiten.

Technisches Beispiel

java

JsonObject payload = Json.createObjectBuilder()
    .add("orderId", orderId.toString())
    .add("status", "ACCEPTED")
    .add("links", Json.createArrayBuilder()
        .add(Json.createObjectBuilder().add("rel", "self").add("href", "/orders/" + orderId)))
    .build();

JsonPatch patch = Json.createPatchBuilder()
    .replace("/status", "SHIPPED")
    .build();

Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.

Enterprise-Fallen

Für einfache DTO-Bindings zu viel Low-Level-Code.
Fehlende Validierung.

Legacy-Modernisierung

Legacy XML/Map-Strukturen können schrittweise in JSON-Dokumente transformiert werden.

Vertiefung: Review-Fragen für Senior-Entwickler

Welche Spezifikation ist hier wirklich nötig?
Welche Runtime-Funktion wird genutzt und ist sie portabel?
Wo liegt die Transaktionsgrenze?
Sind API-Verträge, DTOs und Domain-Modelle getrennt?
Ist der Code ohne Application Server testbar?

Jakarta JSON Binding Index