HTTP-Aufruf – kein Java-Methodenaufruf

1. Methode im Speicher, HTTP im Netzwerk

Wenn Sie zum ersten Mal „mache einen HTTP-Request“ hören, übersetzt das Gehirn eines Java-Entwicklers das oft automatisch in „na ja, das ist wie ein Methodenaufruf, nur übers Internet“. In der Praxis ist genau dieser Gedanke später für die Hälfte der seltsamen Bugs verantwortlich: von „warum gibt es hier keinen Wert“ bis „warum hängt alles“. Lassen Sie uns die Grenze gleich festlegen, bevor sie Ihnen eine Debugging-Party beschert.

An dieser Stelle ist das Austauschformat bereits vollständig sichtbar: Der Client erstellt einen request, sendet ihn übers Netzwerk und erhält einen response zurück. In Logs und Tools sieht das aus wie ein Nachrichtenaustausch, nicht wie ein „Sprung in fremden Code“. Aus diesem Bild ergibt sich die wichtigste Erkenntnis der Vorlesung: Ein HTTP-Aufruf kann nicht mit einem gewöhnlichen Java-Methodenaufruf gleichgesetzt werden.

Ein Java-Methodenaufruf hat eine sehr klare Mechanik: Die JVM führt Code innerhalb eines Prozesses aus, mit einem Speicher, mit denselben Typen, mit einem Aufrufstapel. Ein HTTP-Aufruf ist nicht „eine fremde Methode ausführen“, sondern eine strukturierte Nachricht senden (request) an ein anderes Programm und auf eine andere strukturierte Nachricht (response) warten. Zwischen Ihnen und dem Ergebnis liegt eine ganze Schicht Realität: Datenserielleisierung, Netzwerk, serverseitiges Routing, Antwortformat, status, Verzögerungen und manchmal einfach „niemand hat geantwortet“.

Um dies nicht nur auf der Ebene „weil man es gesagt hat“ zu verankern, vergleichen wir die beiden Welten in einer Tabelle.

Wenn Sie diese Tabelle im Kopf behalten, entwickeln Sie den richtigen „Ingenieursreflex“: HTTP ist ein separates Universum, und man muss es anders behandeln.

2. Lokaler Methodenaufruf in Java

Um den Kontrast zu spüren, ist es hilfreich, kurz in die vertraute Welt der Java-Methoden zurückzukehren und zu sehen, wie „heimelig“ dort alles ist. Wenn Sie eine Methode aufrufen, bauen Sie keine Nachrichten, denken nicht über Netzwerkwege nach und prüfen keinen Statuscode des Ergebnisses. Sie sagen einfach zur JVM: „führe diesen Codeabschnitt aus“ – und erhalten einen Wert. Alles geschieht in einem Speicher, unter der Kontrolle eines Prozesses.

Hier ist ein minimales Beispiel für einen lokalen Aufruf. Es wirkt langweilig – und das ist gut. Langeweile bedeutet hier Vorhersagbarkeit.

public class LocalCallExample {

    static String localTitle() {
        // Lokale Methode: wird direkt in dieser JVM ausgeführt
        return "Clean Code";
    }

    public static void main(String[] args) {
        // Gewöhnlicher Methodenaufruf: kein Netzwerk, keine Status, keine Header
        String title = localTitle();
        System.out.println(title); // Clean Code
    }
}

Was ist hier außer dem Offensichtlichen wichtig?

Erstens: Der Ergebnistyp ist Ihnen im Voraus bekannt. Die Methode ist als String deklariert, also erhalten Sie einen String (oder das Programm stürzt mit einer exception ab, aber „leise etwas Seltsames zurückgeben“ kann eine Methode nicht). Zweitens: Alles geschieht im gemeinsamen Speicher. Der Rückgabewert ist ein Objekt/Wert, das/derselbe in derselben JVM lebt. Sie müssen ihn nicht „decodieren“ oder aus Text „auspacken“.

Drittens: Ein lokaler Aufruf gibt entweder einen Wert zurück oder wirft eine Exception. Und diese Exception ist Teil Ihres Programms: Sie können sie mit try/catch abfangen, den stack trace ansehen, die Zeile sehen, wo etwas kaputtging, und sich sorgfältig darum kümmern.

Schließlich: Eine lokale Methode ist „eigener Code“. Selbst wenn sie in einem anderen Paket (package) liegt und von einem Kollegen geschrieben wurde, können Sie den Quellcode öffnen, einen Breakpoint setzen und sehen, was passiert. Bei einem HTTP-Aufruf haben Sie diesen Luxus normalerweise nicht: Sie interagieren mit einem fremden System über einen Vertrag, nicht über Zugriff auf Quellen und Debugger.

3. HTTP-Aufruf: Anfrage und Antwort

Begeben wir uns jetzt in die Transportwelt. Ein HTTP-Aufruf beginnt nicht mit „eine Funktion aufrufen“, sondern mit „eine Nachricht erstellen“. Sie entscheiden, welche method, welcher path, welche headers und ob es einen body gibt. Dann senden Sie diese Nachricht übers Netzwerk – und was auf der anderen Seite passiert, entzieht sich Ihrer direkten Kontrolle.

Auf konzeptioneller Ebene kann man HTTP-request und HTTP-response sogar als einfache Datenstrukturen beschreiben (in der Realität sind sie natürlich komplexer, aber uns geht es um die Idee „das ist ein separates Nachrichtenobjekt“).

import java.util.Map;

public record HttpRequestData(
        String method, // HTTP-Methode: GET/POST/PUT/DELETE usw.
        String pathWithQuery, // Pfad und Query-Parameter, z. B.: /search?q=clean+code
        Map<String, String> headers, // Header (Metadaten der Anfrage)
        String body // Anfragebody (Nutzlast), oft JSON
) { }

Und die Antwort:

import java.util.Map;

public record HttpResponseData(
        int status, // HTTP-Status: 200, 404, 500 usw.
        Map<String, String> headers, // Antwortheader (Metadaten der Antwort)
        String body // Antwortbody (Daten oder Fehlerbeschreibung)
) { }

Beachten Sie das Gefühl: Bei einem lokalen Aufruf erwarten Sie einen String title, aber in der HTTP-Welt erwarten Sie einen Umschlag (response). Selbst wenn die „Hauptdaten“ im body liegen, existieren sie nicht im luftleeren Raum: Ihre Bedeutung hängt vom status und manchmal von den headers ab. Das haben wir bereits in der Vorlesung über response gesehen: Derselbe body bei unterschiedlichen Status kann völlig unterschiedliche Dinge bedeuten.

Um den Unterschied visuell zu verankern, hier ein vereinfachtes Ablaufdiagramm eines HTTP-Aufrufs:

sequenceDiagram
    %% Vereinfachtes Diagramm: request/response sind separate Nachrichten, die durch das Netzwerk reisen
    participant C as "Client (Ihr Code/Werkzeug)"
    participant N as "Netzwerk"
    participant S as "Server (andere Anwendung)"

    C->>N: "HTTP request senden (method + path + headers + body)"
    N->>S: Bytes liefern
    S->>S: Request parsen und Handler auswählen
    S-->>N: "HTTP response zurückgeben (status + headers + body)"
    N-->>C: Bytes liefern

Der entscheidende Punkt: Sie können dies nicht als „Methode aufgerufen und Wert erhalten“ betrachten, weil zwischen „aufgerufen“ und „erhalten“ viele Gründe liegen, warum Sie gar nichts, einen Fehlerstatus, ein unerwartetes Format oder eine langsame Antwort erhalten können.

4. Objekte vs Bytes: Man kann kein Objekt per HTTP übertragen

Die nächste Falle für Anfänger klingt so: „Naja, in Java arbeite ich mit Objekten, also werde ich auch per HTTP ein Objekt übertragen.“ Innerhalb eines Prozesses stimmt das fast: Sie übergeben eine Referenz auf ein Objekt oder einen Wert. Im Netzwerk gibt es keine Objektreferenzen, weil das andere Programm einen eigenen Speicher hat. Zwischen Anwendungen reisen Bytes, also müssen die Daten in etwas Transportierbares umgewandelt werden: Text, JSON, binäres Format usw.

Genau dafür hat eine HTTP-Nachricht einen body: Hier legen Sie die „Nutzlast“ ab. Vorerst können Sie sich den body einfach als einen String vorstellen.

Vergleichen Sie: Lokal können Sie ein Objekt zurückgeben…

public record Book(String title, String author) { } // Domänendaten: Objekt im JVM-Speicher

public class LocalDomainExample {

    static Book localBook() {
        // Objekt direkt zurückgeben: es lebt im selben Speicher wie der aufrufende Code
        return new Book("Clean Code", "Robert C. Martin");
    }
}

…, aber „per HTTP“ haben Sie meistens so etwas:

public class RemoteBodyExample {

    static String remoteBody() {
        // Übers Netzwerk „fliegen“ Bytes: meistens Text (z. B. JSON), kein Book-Objekt
        return """
               {"title":"Clean Code","author":"Robert C. Martin"}
               """;
    }
}

Der zweite String ist kein Book-Objekt. Es ist Text (eine Zeichenfolge), der nach Vereinbarung als Buch interpretiert werden kann. Und hier beginnt eine wichtige Arbeit: Damit zwei Anwendungen einander verstehen, müssen sie sich darauf einigen, wie genau der Text im body die Daten beschreibt. Und wenn die Vereinbarung verletzt wird – liest eine der Anwendungen „das Falsche“.

Auch wenn das jetzt wie eine Kleinigkeit wirkt, ist der Gedanke einfach: Bei einem lokalen Aufruf schützen Sie die Typen fast automatisch, bei einem HTTP-Aufruf entsteht Schutz nur, wenn Sie selbst diszipliniert mit dem Austauschvertrag umgehen.

5. Ergebnis: return/exception und status/body

Bei einer lokalen Methode ist das Ergebnis entweder ein return oder eine exception. Bei einem HTTP-Aufruf gibt es mindestens drei verschiedene Situationen, die ein Anfänger oft in einen Topf wirft:

Erste Situation – der Server hat geantwortet, und Sie haben einen response. Das bedeutet: Sie haben einen status, möglicherweise headers, möglicherweise einen body. Selbst wenn der status „Fehler“ sagt, ist das trotzdem eine vollständige Antwort.

Zweite Situation – der Server hat nicht geantwortet, weil Sie keine Verbindung herstellen konnten, das Netzwerk ausgefallen ist, die Adresse falsch war, die Verbindung abgerissen ist oder Sie die Antwort nicht abgewartet haben. In dieser Situation haben Sie möglicherweise überhaupt kein HttpResponseData.

Dritte Situation – der Server hat „scheinbar erfolgreich“ geantwortet, aber der body ist leer/unerwartet/nicht im richtigen Format. Und das ist ein separates Problem: Formal gibt es eine Antwort, aber die „Daten, die Sie wollten“, fehlen.

Versuchen wir, das in ganz einfachem Pseudocode darzustellen, ohne Bindung an einen bestimmten HTTP-Client (denn unser Ziel ist ein mentales Modell, nicht eine Bibliothek).

public class RemoteResultExample {

    String handle(HttpResponseData response) {
        // 1) Zuerst den Status prüfen: das ist der „Umschlag“, ohne ihn kann man body nicht verstehen
        if (response.status() != 200) {
            // Server hat geantwortet, aber einen Fehler per HTTP-Status gemeldet
            return "Server hat mit Fehler geantwortet: status=" + response.status();
        }

        // 2) Erst nach erfolgreichem Status macht es Sinn, Daten aus dem body zu lesen
        return "Daten aus body: " + response.body();
    }
}

Beachten Sie: In der lokalen Welt schreiben Sie normalerweise kein if (ok) um jeden Aufruf herum. In der HTTP-Welt ist das jedoch ein völlig normaler Teil des Lebens: zuerst verstehen, welcher status vorliegt, und erst dann entscheiden, wie der body zu interpretieren ist.

Genau deshalb zerstört das Denken „HTTP-Aufruf ≈ Methode“ die Architektur. Der Entwickler erwartet einen „Rückgabewert“ und ist genervt von der Notwendigkeit, den Status zu lesen. Aber der status ist keine „überflüssige Bürokratie“, sondern ein Teil des Vertrags: Der Server ist nicht verpflichtet, Ihnen Daten zu geben, er ist verpflichtet, ehrlich mitzuteilen, was passiert ist.

6. Zeit und Unsicherheit bei HTTP

Es gibt noch eine Sache, die in der Methodenwelt oft unsichtbar ist: die Zeit. Ein lokaler Methodenaufruf ist im Vergleich zu jedem I/O normalerweise eine mikroskopische Operation. Ein HTTP-Aufruf ist nahezu reiner I/O. Selbst wenn der Server schnell arbeitet, haben Sie ein Netzwerk, das gerne unberechenbar ist: mal normal, mal langsam, mal „oh, das WLAN denkt über den Sinn des Lebens nach“.

Man kann das sogar an einem Spielzeugbeispiel spüren. Eine lokale Methode wird sofort aufgerufen:

public class TimingExample {

    static String localTitle() {
        // Lokale Operation: keine Wartezeiten durch Netzwerk, Festplatte usw.
        return "Clean Code";
    }

    public static void main(String[] args) {
        // Wichtig: nanoTime() – zur Messung von Dauern, nicht für „aktuelle Zeit“
        long start = System.nanoTime();
        localTitle();
        long end = System.nanoTime();

        // Hier steht fast immer eine „sehr kleine Zahl“
        System.out.println("ns = " + (end - start)); // ns = <sehr kleine Zahl>
    }
}

Die Zahl wird klein sein (und bei verschiedenen Läufen unterschiedlich), aber die Idee ist, dass ein lokaler Aufruf in Nanosekunden/Mikrosekunden gemessen wird, während Sie jeden echten HTTP-Aufruf in Millisekunden und manchmal in Sekunden spüren werden. Das ist keine „schlechte Bibliothek“ und nicht „Java ist langsam“. Das ist die Physik der Welt: Sie kommunizieren mit einem anderen Programm, oft über mehrere Netzwerkknoten.

Daraus ergibt sich eine einfache Gewohnheit eines Backend-Entwicklers: Ein HTTP-Aufruf wird als teure Operation behandelt. Man macht ihn nicht „für den Fall der Fälle“, packt ihn nicht in sinnlose Schleifen und erwartet nicht, dass er immer schnell ist.

7. Verträge: Signatur und HTTP

Es gibt noch einen weiteren Grund, warum man einen HTTP-Aufruf nicht mit einem Methodenaufruf gleichsetzen kann: Der Vertrag ist in diesen Welten unterschiedlich aufgebaut. Bei einer Methode ist der Vertrag ihre Signatur und ihre Typen. Der Compiler hilft Ihnen: Sie ändern den Argumenttyp – sofort wird die Hälfte des Projekts rot, und das ist wunderbar (es tut weh, aber es heilt).

Bei einem HTTP-Vertrag gibt es keinen „Compiler“. Es gibt Vereinbarungen: welche method, welcher path, welche headers, ob es einen body gibt, welches Datenformat, welcher Status für Erfolg und welcher für Fehler gilt. Wenn Sie auf einer Seite etwas am Vertrag ändern, erfährt die andere Seite davon möglicherweise erst zur Laufzeit, und zwar im ungünstigsten Moment: wenn der Benutzer schon auf den Knopf drückt und es bereits zu spät ist.

Vergleichen wir ganz praktisch:

Und genau deshalb zwingt Sie das Backend-Denken, HTTP als separate Disziplin zu betrachten. Sie „rufen nicht einfach eine Methode remote auf“. Sie betreten eine Welt von Verträgen und Nachrichten, in der Details wichtig sind, und diese Details kann man nicht ohne Konsequenzen unter den Teppich kehren.

8. ReadLater Starter: Grenze der Systeme

In unserem Projekt ReadLater Starter wird dieser Unterschied ständig auftauchen, auch wenn Sie noch keine einzige Zeile Code für HTTP geschrieben haben. Laut Projektplan gibt es einen externen Buchkatalog (einen separaten Dienst) und unsere Anwendung, die mit ihm kommuniziert. Und hier ist es wichtig zu verstehen: Selbst wenn Sie zu 100 % verstehen, dass „da draußen eine API ist“, wird Ihr Gehirn dennoch versuchen zu schummeln und denken: „na ja, ich will doch nur eine Liste von Büchern bekommen, also ist das wie catalog.search()“.

Das richtige Bild ist: catalog.search() innerhalb unserer Anwendung (falls Sie es implementieren) ist eine lokale Methode, die irgendwann einen HTTP-Request erzeugt, ihn nach draußen sendet, einen HTTP-Response erhält, den status prüft und erst dann den body in etwas Bequemes für den Rest des Programms umwandelt.

Das heißt, innerhalb der Anwendung werden Sie tatsächlich mit Methoden arbeiten. Aber die Grenze nach außen wird immer wie „Nachricht hin – Nachricht zurück“ aussehen. Es ist nützlich, das selbst auf alltäglicher Ebene zu behalten: Wenn Sie eine Zeile wie https://.../search?q=clean+code sehen, ist das kein „Methodenname im Internet“. Es ist ein Teil der Adresse für eine Nachricht, die an ein anderes System geht. Und sobald diese Grenze normal wird, liest man auch method und path anders: Das sind nicht mehr „Namen einer entfernten Funktion“, sondern Teile eines Vertrags zwischen zwei Systemen.

Genauso: Wenn jemand unsere Anwendung per HTTP aufruft (z. B. aus einem Browser oder einem anderen Tool), wird er nicht „unsere Methode aufrufen“. Er wird einen request senden, und wir werden entscheiden, welches Code-Stück darauf antworten soll und in welcher Form wir den response zurückgeben.

Wenn Sie dieses Bild im Kopf behalten, wird die Projektarchitektur sauberer: Lokaler Code kann mit Typen und Methoden entworfen werden, externe Interaktionen mit Nachrichtenverträgen.

9. Typische Fehler bei HTTP-Aufrufen

Fehler Nr. 1: Denken, dass ein HTTP-Aufruf „einen Wert zurückgeben muss“, wie eine Methode.
Ein Anfänger erwartet psychologisch, dass, wenn er „aufgerufen“ hat, auch „zurückgegeben“ wird. In der HTTP-Welt kann ein response mit einem Fehler-status zurückkommen, ein leerer body, oder es kann überhaupt nichts zurückkommen, weil das Netzwerk oder die Adresse versagt haben. Die richtige Gewohnheit ist: zuerst die Realität des response (oder seines Fehlens) akzeptieren und erst dann über Daten sprechen.

Fehler Nr. 2: Nur den body lesen und den status ignorieren.
Das ist fast wie im richtigen Leben: nur den Inhalt des Briefes ansehen und den Stempel „Empfänger nicht gefunden“ ignorieren. Der Antwortbody allein garantiert nicht, dass die Anfrage erfolgreich war. Wenn Sie den Status nicht beachten, können Sie freudig versuchen, den Fehlertext als Daten zu parsen und sich dann lange wundern, „warum mein JSON kaputt ist“.

Fehler Nr. 3: „Server hat mit Fehler geantwortet“ und „Server hat überhaupt nicht geantwortet“ vermischen.
Eine Antwort mit einem Fehlerstatus ist trotzdem eine Antwort: Die Verbindung bestand, das Protokoll hat funktioniert, der Server hat etwas mitgeteilt. Ein Netzwerkfehler ist eine andere Situation: Sie sind noch nicht einmal zur Phase des Erhaltens eines response gelangt. Diese Fälle erfordern unterschiedliches Denken und im echten Code eine unterschiedliche Behandlung.

Fehler Nr. 4: Versuchen, gedanklich „ein Objekt per HTTP zu übertragen“.
Innerhalb der JVM übergeben Sie Werte und Referenzen. Per HTTP übertragen Sie Bytes. Wenn Sie diese Grenze nicht im Griff haben, entwickeln Sie Erwartungen wie „na ja, ich habe ein Book gesendet, warum ist auf der anderen Seite kein Book“. Auf der anderen Seite gibt es Ihren Speicher, Ihre Klassen und Ihre Referenzen nicht – nur das, was Sie tatsächlich in den body gelegt haben.

Fehler Nr. 5: Von einem HTTP-Aufruf die gleiche Geschwindigkeit und Stabilität erwarten wie von einer Methode.
Ein lokaler Methodenaufruf ist normalerweise sehr schnell. Ein HTTP-Aufruf ist I/O, und I/O kann langsam sein. Wenn Sie im Kopf „wie eine Methode“ verankern, werden Sie den entfernten Dienst zu oft, zu tief in der Logik aufrufen und dann auf eine „unerklärliche Verzögerung“ stoßen. Selbst in Übungsprojekten ist es nützlich, das Gefühl zu bewahren: „Das ist eine teure Operation“.