‏ ‏ ‎ ‏ ‏ ‎

Mitschrift vom 02.03.2026 (Simone)

1. Testtermine

  • 24. November 2025

  • 19. Jänner 2026

2. 2025-09-15

2.1. Konzepte

2.1.1. Internet für Menschen / Personen

  • Webseiten mit html / js / css

2.1.2. Internet für Maschinen und Prozesse (verteilte Systeme)

  • (SOAP)

  • REST

  • graphQL

  • gRPC

  • WebSockets

  • SSE

  • MQTT

2.1.3. REST

  • REpresentational State Transfer

  • HTTP Methoden

  • Übertragung beliebiger Text- (HTML, XML, JSON, …​) und Binärformate (Images, PDF, …​)

  • jedoch relativ starr

  • gut geeignet für CRUD Operationen (Create, Read, Update, Delete)

  • mehrere Endpoint URLs

  • Overhead durch HTTP Header

proprietär …​ firmenspezifisch (nicht offengelegt, nicht standardisiert, nicht interoperabel)

2.1.4. graphQL

  • von Facebook entwickelt

  • Abfragesprache für APIs

  • flexible Abfragen

  • nur eine einzige Endpoint URL

  • gut geeignet für komplexe Datenstrukturen

  • weniger Overhead als REST

  • stark typisiert

2.1.5. gRPC

  • von Google entwickelt

  • Remote Procedure Call (RPC) Framework

  • basiert auf HTTP/2

  • unterstützt mehrere Programmiersprachen

  • effizient und schnell

  • stark typisiert

  • unterstützt Streaming

  • benötigt Protokollpuffer (Protocol Buffers) zur Definition der Schnittstellen

  • gut geeignet für Microservices

2.1.6. WebSockets

  • bidirektionale Kommunikation

  • Echtzeit-Anwendungen

  • text- und binäre Daten

2.1.7. SSE (Server-Sent Events)

  • unidirektionale Kommunikation (Server zu Client)

  • Echtzeit-Updates

  • textbasierte Daten (meist JSON)

  • einfach zu implementieren

  • gut geeignet für Benachrichtigungen, Newsfeeds

2.1.8. MQTT (Message Queuing Telemetry Transport)

  • leichtgewichtiges Publish-Subscribe-Protokoll

  • für IoT (Internet of Things) entwickelt

  • funktioniert über TCP/IP

  • geringerer Overhead

  • gut geeignet für ressourcenbeschränkte Geräte

  • unterstützt QoS (Quality of Service) Level

broker

2.1.9. Publish-Subscribe vs Observer Pattern (vom copilot)

Der Hauptunterschied zwischen Publish-Subscribe und Observer Pattern liegt in der Entkopplung und dem Kommunikationsmodell:

  • Observer Pattern:

    • Direkte Kopplung zwischen Subjekt (Subject) und Beobachtern (Observers).

    • Das Subjekt kennt alle seine Beobachter und benachrichtigt sie direkt bei Änderungen.

    • Wird meist innerhalb einer Anwendung verwendet (z.B. GUI-Events).

  • Publish-Subscribe:

    • Lose Kopplung durch einen Vermittler (Message Broker).

    • Publisher und Subscriber kennen sich nicht direkt.

    • Nachrichten werden an einen Kanal/Topic gesendet und von allen interessierten Subscribern empfangen.

    • Häufig in verteilten Systemen eingesetzt (z.B. MQTT, EventBus).

Zusammengefasst: Observer ist direkt und synchron, Publish-Subscribe ist indirekt, asynchron und skalierbarer.

2.2. Microservices

microservice

3. 2025-10-06

JAX-RS (Jakarta RESTful Web Services) * ist eine Spzifikation (Standard) für die Entwicklung von RESTful Web Services in Java

  • Teil von Jakarta EE (früher Java EE)

3.1. Response Typen bei JAX-RS

  • bei REST-Endpoints können verschiedene Response-Typen zurückgegeben werden, abhängig von der Anforderung und dem Kontext

  • die häufigsten Rückgabetypen der REST-Endpoint-Methoden sind:

    • String

    • Entity zB Person

    • Response: enthält Statuscode, Header und Entity und mehr zB Cookies

    • …​

3.2. JAX-RS mit Datenbanken

4. 2025-09-22

Prüfungsfragen

  • Was ist REST?

  • Welche REST-Anforderungen gibt es?

  • Was ist HTML?

  • Was ist HTTP?

5. 2025-10-06

5.1. Prüfungsfragen – Zusammenfassung

5.1.1. Was ist proprietär?

Proprietär bedeutet firmenspezifisch oder nicht standardisiert. Eine proprietäre Software oder Technologie gehört einem bestimmten Unternehmen, das die Kontrolle über deren Nutzung, Änderung und Weitergabe behält. Beispiel: Microsoft Word ist proprietär, während LibreOffice Open Source ist.

5.1.2. Was ist ein Handshake?

Ein Handshake ist ein Kommunikationsprozess zwischen zwei Systemen (z. B. Client und Server oder Browser und Server), bei dem sie sich gegenseitig über Verbindungsparameter, Verschlüsselung oder Authentifizierung einigen. Beispiel: Beim Aufbau einer HTTPS-Verbindung erfolgt ein TLS-Handshake.

5.1.3. Unterschied Microservice vs. Monolith

  • Monolith: Eine Anwendung besteht aus einem großen Block mit allen Funktionen und Modulen gemeinsam. Änderungen sind oft schwierig und erfordern ein erneutes Deployment der gesamten Anwendung.

  • Microservices: Die Anwendung ist in mehrere kleine, unabhängige Services aufgeteilt. Jeder Service kann separat entwickelt, getestet, deployed und skaliert werden.

5.1.4. GraphQL vs. REST

  • REST:

    • Nutzt mehrere Endpunkte (z. B. /users, /products).

    • Server bestimmt, welche Daten zurückgegeben werden.

    • Kann zu Overfetching oder Underfetching führen.

  • GraphQL:

    • Nur ein einziger Endpunkt.

    • Client bestimmt selbst, welche Daten er benötigt.

    • Spart Bandbreite und reduziert unnötige Datenübertragung.

5.1.5. Was ist referenzielle Integrität?

Die referenzielle Integrität stellt sicher, dass Beziehungen zwischen Tabellen in einer Datenbank konsistent bleiben. Wenn ein Fremdschlüssel in einer Tabelle auf eine andere Tabelle verweist, darf der referenzierte Datensatz nicht gelöscht oder verändert werden, ohne die Beziehung anzupassen. Beispiel: Ein Schüler-Datensatz darf nicht existieren, wenn seine Schule gelöscht wurde.

5.1.6. Master-Detail-Tabellenbeziehung

Eine Master-Detail-Beziehung (auch 1:n-Beziehung) beschreibt, dass: - eine Master-Tabelle (z. B. Kunde) mehrere Detail-Datensätze (z. B. Bestellungen) haben kann. - Die Detail-Tabelle enthält einen Fremdschlüssel zur Master-Tabelle.

5.1.7. Orphaned Record

Ein Orphaned Record (verwaister Datensatz) ist ein Datensatz, der keine Verbindung mehr zu seinem übergeordneten Datensatz hat. Das passiert z. B., wenn ein übergeordneter Datensatz gelöscht wird, aber abhängige Datensätze bestehen bleiben. Dies führt zu Dateninkonsistenz und sollte durch referenzielle Integrität verhindert werden.

5.1.8. Restrict vs. Cascading Delete vs. Nullify

  • Restrict: Das Löschen eines übergeordneten Datensatzes wird verhindert, wenn abhängige Datensätze existieren.

  • Cascading Delete: Beim Löschen eines übergeordneten Datensatzes werden alle abhängigen Datensätze automatisch mitgelöscht.

  • Nullify: Beim Löschen des übergeordneten Datensatzes wird der Fremdschlüssel in den abhängigen Datensätzen auf NULL gesetzt.

5.1.9. Was ist JACKSON?

Jackson ist eine Java-Bibliothek zum (De-)Serialisieren von JSON-Daten. Sie wandelt JSON in Java-Objekte um und umgekehrt. Dieser Prozess wird auch Marshalling (Serialisierung) und Unmarshalling (Deserialisierung) genannt.

5.1.10. Was ist JAX-RS?

JAX-RS (Java API for RESTful Web Services) ist eine Java-Spezifikation zur Erstellung von REST-APIs. Sie verwendet Annotationen wie @GET, @POST, @Path, @Produces, um HTTP-Endpunkte einfach zu definieren.

5.1.11. Was ist ein Singleton?

Das Singleton-Pattern stellt sicher, dass von einer Klasse nur eine Instanz existiert. Diese Instanz ist global zugänglich. Typisches Beispiel: Eine zentrale Logger- oder Konfigurationsklasse.

5.1.12. Convention over Configuration

Ein Software-Prinzip, das besagt: > „Wenn du dich an die Konventionen hältst, musst du nichts konfigurieren.“

Das bedeutet, dass Frameworks Standardverhalten automatisch übernehmen, solange der Entwickler sich an gewisse Namens- oder Strukturkonventionen hält. Beispiel: In Quarkus wird application.properties automatisch erkannt.

5.1.13. Was ist ein Paradigma?

Ein Paradigma ist ein grundlegendes Denk- oder Programmierkonzept, das vorgibt, wie Software strukturiert und entwickelt wird. Beispiele: - Objektorientiert (Java, C++) - Funktional (Haskell, JavaScript) - Prozedural ©

5.1.14. Was ist eine Objektidentität?

Die Objektidentität beschreibt die eindeutige Existenz eines Objekts im Speicher. Zwei Objekte können denselben Inhalt haben, aber verschiedene Identitäten besitzen. In Java wird die Identität durch den Speicherort (Referenz) bestimmt. Beispiel:

Person p1 = new Person("John");
Person p2 = new Person("John");

p1.equals(p2) kann true sein (gleicher Inhalt), aber p1 == p2 ist false (unterschiedliche Identität).

6. 2025-10-13

6.1. CDI - Contexts and Dependency Injection

  • Man erzeugt Objekte nicht selbst mit new, sondern lässt sie vom Framework bereitstellen (Inversion of Control - IoC)

  • zB ohne CDI

    PersonRepository personRepository = new PersonRepository();

  • zB mit CDI

    @Inject
PersonRepository personRepository;

  • mit Dependency Injection (DI) werden die Referenzen auf - bereits vom übergeordneten DI-Container erzeugte - Objekte automatisch gesetzt -man spricht hier von injizieren.

  • Der Begriff Context gibt die Lebensdauer und Sichtbarkeit der Objekte an.

    • @ApplicationScoped

    • @RequestScoped

    • @SessionScoped

    • @Dependent (Standard)

6.2. JPA (Java Persistence API)

7. 2025-11-03

Normalisierung

  • Was ist die 1.NF?

Antwort

  • Jedes Attribut enthält nur atomare Werte (unteilbar).

  • Es gibt keine wiederholten Gruppen oder Mehrfachwerte.

  • Jede Zeile ist eindeutig identifizierbar (durch Primärschlüssel).

  • Was ist die 2.NF?

Antwort

  • Erfüllt die Anforderungen der 1.NF.

  • Jedes Nicht-Schlüsselattribut ist vollständig funktional abhängig vom gesamten Primärschlüssel (nicht nur von einem Teil davon, wenn der Primärschlüssel aus mehreren Attributen besteht).

  • Was ist die 3.NF?

Antwort

  • Erfüllt die Anforderungen der 2.NF.

  • Es gibt keine transitiven Abhängigkeiten zwischen Nicht-Schlüsselattributen. (Ein Nicht-Schlüsselattribut darf nicht von einem anderen Nicht-Schlüsselattribut abhängen).

  • Warum tut man normalisieren?

Antwort

  • Zur Abfragen der Daten nach unterschiedlichen Dimensionen (zB Kunde nach Region, Produktkategorie, Zeiträume, …​). Die Fakten (Measures) sind meist numerische Werte (zB Umsatz, Menge, …​), die analysiert werden.

  • Reduziert Datenredundanz und Inkonsistenzen.

  • Verbessert Datenintegrität.

  • Erleichtert Wartung und Updates der Datenbank.

informationswuerfel

8. 2025-11-10

1. Test – Stoff

  • Datenmodell aufsetzen

  • Testfälle schreiben

  • AssertJ-DB

  • REST-Services

Was sind Entity-Klassen?

  • Java-Klassen, die mit @Entity annotiert sind

  • Werden per JPA/Hibernate einer Datenbanktabelle zugeordnet

  • Felder entsprechen Tabellenspalten

  • Besitzen mindestens einen Primärschlüssel (@Id)

  • Dienen als Abbild der tatsächlichen Geschäftsobjekte (z. B. User, Product, Cart) → Bsp: Früher wurden diese Daten in Aktenschränken / -ordnern aufbewahrt, heute in Datenbanken.

filing cabinet

8.1. Klassendiagramm angezeigt bekommen

  • Klassen markieren → Rechtsklick → Diagrams → Java Klassen → Diagram wird angezeigt

    • Fields und show Dependencies anklicken → Beziehungen und Attribute werden angegzeigt.

    • Rechtsklick im Diagramm → Layout → Nets → organic

    • Rechtsklick im Diagramm → Appearance → Standard

8.2. Beziehungen

8.2.1. Fetch-Strategien — LAZY vs. EAGER

  • LAZY (Standard bei 1:n, n:m) Daten werden erst geladen, wenn darauf zugegriffen wird → bessere Performance

  • EAGER (Standard bei 1:1, n:1) Verknüpfte Daten werden sofort mitgeladen → kann mehr laden als nötig

Faustregel: → Immer LAZY, außer es gibt einen guten Grund.

8.2.2. Kardinalität / Multiplizität

Annotation

Beziehung

Bedeutung

@OneToOne

1 : 1

Ein Objekt → ein Objekt

@OneToMany

1 : n

Ein Objekt → viele

@ManyToOne

n : 1

Viele → eins

@ManyToMany

n : m

Viele ↔ viele

8.2.3. Triple-A-Pattern (AAA)

Strukturierungskonzept für Unit-Tests → klar, einfach, gut lesbar.

  • Arrange Test vorbereiten: Objekte anlegen, Daten initialisieren, mocks konfigurieren

  • Act Aktion ausführen: die zu testende Methode aufrufen

  • Assert Ergebnis prüfen: Erwartetes Resultat mit tatsächlichem vergleichen

Beispiel
@Test
void testAdd() {
    // Arrange
    Calculator calc = new Calculator();

    // Act
    int result = calc.add(2, 3);

    // Assert
    assertEquals(5, result);
}

8.2.4. Stammdaten & Bewegungsdaten

  • entstehen in Geschäftsprozessen

  • Stammdaten

    • Langfristig gültige (mehrere Geschäftsjahre), selten veränderte Grunddaten (ev. die Adresse eines Kunden oder Mitarbeiters)

    • Beschreiben Objekte/Personen unabhängig von Vorgängen

    • Beispiele: Kunden, Produkte, Mitarbeiter

  • Bewegungsdaten

    • sind meist einer Periode zuzuordnen, zB einem Geschäftsjahr

    • Verändern sich laufend, beziehen sich auf Stammdaten

    • werden eher nie verändert: zB wird eine Rechnung nicht mehr geändert, wenn sie einmal erstellt wurde

    • Beispiele: Bestellungen, Rechnungen, Buchungen

stammdaten bewegungsdaten

9. 2026-01-12

9.1. Informationswürfel

9.2. ORM / JPA

9.3. Panache

9.3.1. Paging

9.4. Sorting

9.5. Query Methods

9.6. Beispiel Panache

10. 2026-02-09

10.1. graphQL

  • Warum graphQL?

    • Flexibilität: Clients können genau die Daten anfordern, die sie benötigen, und nicht mehr.

    • Effizienz: Reduziert die Anzahl der Anfragen, da mehrere Ressourcen in einer einzigen Anfrage abgefragt werden können.

    • Starke Typisierung: Das Schema definiert die verfügbaren Daten und deren Typen,was die Entwicklung und Fehlersuche erleichtert.

    • Echtzeit-Updates: Unterstützt Subscriptions für Echtzeit-Kommunikation.

    • Gute Dokumentation: Das Schema dient als Dokumentation der API

10.2. Angular-Beispiel

  • Routing

11. 2026-02-23

  • graphQL-Beispiel besprochen

  • Was ist ein graphQL-Schema?

    • Ein graphQL-Schema definiert die Struktur der Daten, die von einem graphQL-Server bereitgestellt werden. Es beschreibt die verfügbaren Typen, Felder und Beziehungen zwischen den Daten.

    • Es dient als Vertrag zwischen Client und Server, der festlegt, welche Daten abgefragt werden können und wie sie strukturiert sind.

  • graphQL-Endpoint

package at.htl.vehicle.boundary;

import at.htl.vehicle.control.VehicleRepository;
import at.htl.vehicle.entity.Vehicle;
import org.eclipse.microprofile.graphql.*;

import jakarta.inject.Inject;
import jakarta.transaction.Transactional;
import java.util.List;

@GraphQLApi
public class VehicleGraphQlApi {

    @Inject
    VehicleRepository vehicleRepository;

    @Query("allVehicles")
    @Description("Get all vehicles from the gallery")
    public List<Vehicle> getAllVehicles() {
        return vehicleRepository.listAll();
    }

    @Query("vehicle")
    @Description("Get a specific vehicle by its id")
    public Vehicle getVehicle(@Name("vehicleId") Long id) {
        return vehicleRepository.findById(id);
    }

    @Mutation("createVehicle")
    @Description("Add a new vehicle to the gallery")
    @Transactional
    public Vehicle createVehicle(Vehicle vehicle) {
        vehicleRepository.persist(vehicle);
        return vehicle;
    }

    @Mutation("deleteVehicle")
    @Description("Remove a vehicle from the gallery")
    @Transactional
    public boolean deleteVehicle(@Name("vehicleId") Long id) {
        return vehicleRepository.deleteById(id);
    }
}

  • graphQL-Clients

    • Debug-page

    • intellij-client

    • cli-Tools (zB curl, httpie, httpyac, …​)

12. 2026-03-02

12.1. Welche Parameter-typen gibt es bei http? (S. Sperrer)

12.1.1. Pathparam

Beispiel eines GET-Requests mit Pathparam
https://www.beispiel.de/api/users/123

Hier ist 123 ein Pathparam, der die ID des Benutzers angibt, den wir abrufen möchten.w

12.1.2. Queryparam

Beispiel eines GET-Requests mit Queryparam
https://www.beispiel.de/api/users?name=Max&age=30

Hier sind name=Max und age=30 Queryparameter, die zusätzliche Informationen über die Anfrage liefern (z. B. Filterkriterien).

12.1.3. Bodyparam

  • Werden im Body der http-Anfrage gesendet

  • Hauptsächlich bei POST- oder PUT-Requests

  • Meistens im JSON-Format

Beispiel eines POST-Requests mit Bodyparam
{
"name": "Max Muster",
"email": "max@muster.com"
}

12.1.4. Headerparam

Der Header enthält Metadaten über die Anfrage selbst.

z.B. Authentifizierungstoken

Beispiel:
Content-Type: application/json

12.2. Aufbau eines http-requests (Anfrage)

Ein Client (zB Browser) sendet einen Request an den Server.

Komponente Beschreibung

Startzeile

Enthält Methode, Pfad und Version (z.B. GET /index.html HTTP/1.1).

Header

Metadaten wie Host, User-Agent oder Accept. key-value Paare, die Informationen über die Anfrage liefern.

Leerzeile

Trennt Header vom Body.

Body

Enthält Daten (optional, primär bei POST/PUT).
Beispiel eines POST-Requests
POST /api/login HTTP/1.1
Host: www.beispiel.de
Content-Type: application/json
Content-Length: 34

{
  "user": "admin",
  "pass": "1234"
}

12.3. Aufbau der HTTP-Response (Antwort)

Der Server antwortet auf den Request mit dem Ergebnis der Verarbeitung.

Komponente Beschreibung

Statuszeile

Enthält Version, Statuscode und Nachricht (z.B. HTTP/1.1 200 OK).

Header

Infos vom Server (z.B. Content-Type, Server, Set-Cookie). key-value Paare, die Metadaten über die Antwort liefern.

Leerzeile

Trennt Header vom Body.

Body

Die eigentlichen Daten (HTML, JSON, Bild).
Beispiel einer erfolgreichen Antwort
HTTP/1.1 200 OK
Date: Mon, 02 Mar 2026 10:30:00 GMT
Server: Apache/2.4.41
Content-Type: text/html

<html>
  <body>
    <h1>Willkommen!</h1>
  </body>
</html>

12.4. WebSockets

WebSockets wurden entwickelt, um die Einschränkungen des klassischen HTTP-Protokolls zu überwinden und echte Interaktivität im Browser zu ermöglichen.

12.4.1. Das Kernproblem: Die HTTP-Einbahnstraße

Traditionelles HTTP folgt einem strikten Request-Response-Modell.

  • Zustandslosigkeit: Jede Anfrage steht für sich allein.

  • Client-getrieben: Der Server darf nicht von sich aus sprechen. Er muss warten, bis der Browser fragt: "Gibt es etwas Neues?"

  • Overhead: Für jede kleine Nachricht (z. B. ein "Hi" im Chat) müssen HTTP-Header mitgeschickt werden, was Bandbreite und Zeit kostet.

12.4.2. Die Lösung durch WebSockets

Ein WebSocket ermöglicht eine Full-Duplex-Verbindung. Nach einem initialen Handshake bleibt die Verbindung offen.

  • Server-Push: Der Server sendet Daten sofort, wenn sie entstehen.

  • Geringe Latenz: Kein ständiger Verbindungsaufbau nötig.

  • Effizienz: Die Header-Daten sind nach dem Handshake minimal.

12.4.3. Unterschied: WebSocket vs. Socket

Obwohl die Namen ähnlich sind, arbeiten sie auf unterschiedlichen Abstraktionsebenen des Netzwerks.

Merkmal Klassischer Socket (TCP) WebSocket

OSI-Schicht

Schicht 4 (Transport)

Schicht 7 (Anwendung)

Protokoll

Pures TCP

Basiert initial auf HTTP (Upgrade)

Einsatzort

Systemprogrammierung (C++, Java, Go)

Webbrowser und Webserver

Firewalls

Oft blockiert (außer Standardports)

Passiert Port 80/443 problemlos. Firewalls erkennen es als normalen HTTP-Verkehr.

Abstraktion

"Roh" (Byte-Streams)

Nachrichtenbasiert (Frames)

12.5. 1. Sockets (Network Sockets)

Ein Socket ist der fundamentale Endpunkt einer Netzwerkverbindung im Betriebssystem.

Programmierer müssen bei Sockets oft selbst definieren, wo eine Nachricht anfängt und wo sie aufhört (Framing).

12.5.1. WebSockets

WebSockets sind ein Protokoll, das auf Sockets aufbaut. Da Browser aus Sicherheitsgründen keinen direkten Zugriff auf rohe TCP-Sockets erlauben, fungiert der WebSocket als "sicherer Proxy" für Web-Anwendungen.

12.5.2. Typische Anwendungsfälle

  • Finanz-Apps: Live-Aktienkurse ohne Verzögerung.

  • Collaboration Tools: Wenn mehrere Personen gleichzeitig an einem Dokument arbeiten.

  • Gaming: Multiplayer-Browser-Spiele mit schnellen Reaktionszeiten.

  • Messenger: Sofortige Zustellung von Chat-Nachrichten.

Wähle WebSockets, wenn du eine dauerhafte Verbindung für bidirektionalen Datenaustausch im Web benötigst. Nutze Sockets, wenn du außerhalb des Browsers maximale Kontrolle über den Netzwerkverkehr brauchst.

12.6. Exkurs: GraphQL vs. REST Response-Handling in Quarkus

In Quarkus (SmallRye GraphQL) ist es ein fundamentaler Unterschied zu JAX-RS (REST), wie Antworten an den Client gesendet werden.

12.6.1. Die kurze Antwort

In GraphQL ist es absolut unüblich, ein generisches Response-Objekt (wie javax.ws.rs.core.Response) zurückzugeben.

Während du in REST Header, Statuscodes und Body manuell verpackst, übernimmt bei GraphQL das Framework die Kapselung der Daten.

12.6.2. Warum kein Response-Objekt?

1. Der HTTP-Statuscode ist (fast) immer 200

Im Gegensatz zu REST landen alle GraphQL-Anfragen per POST auf einem einzigen Endpunkt (meist /graphql). * Selbst bei fachlichen Fehlern antwortet der Server technisch mit einem HTTP 200 OK. * Fehlerinformationen werden im errors-Feld des JSON-Bodys transportiert, nicht über den HTTP-Header.

2. Automatische Kapselung durch SmallRye

Wenn du ein POJO oder eine Entity zurückgibst, baut das Framework automatisch das standardisierte GraphQL-Antwortformat:

{
  "data": {
    "user": { "id": "1", "name": "Max" }
  },
  "errors": []
}
3. Fehlerbehandlung via Exceptions

Statt Response.status(404).build() zu nutzen, wirfst du in GraphQL einfach eine Exception. Diese wird automatisch in das errors-Array übersetzt.

12.6.3. Vergleich: REST vs. GraphQL

Feature REST (JAX-RS) GraphQL (SmallRye)

Rückgabetyp

Response oder Entity

Direktes Daten-Objekt (POJO/Entity)

Statuscodes

200, 201, 400, 404, 500 etc.

Fast immer 200 OK

Fehler-Handling

Response-Builder

Exceptions (werden zu errors)
Code-Beispiel (Quarkus GraphQL)

So implementierst du einen sauberen Endpoint ohne manuelles Response-Objekt:

@Query
public User getUser(Long id) {
    User user = repository.findById(id);
    if (user == null) {
        // Diese Exception wird vom Framework in einen GraphQL-Error gewandelt
        throw new GraphQLException("User mit ID " + id + " nicht gefunden");
    }
    return user; // Das Framework kümmert sich um das JSON-Gerüst
}

Das Response-Objekt gehört zur JAX-RS Spezifikation. In der MicroProfile GraphQL Spezifikation arbeitest du stattdessen mit echten Typen, was deine API typsicherer und einfacher testbar macht.