Heutzutage sind ja REST Services sehr beliebt. Normalerweise läuft dieser Aufruf synchron ab und der Thread wartet schön, bis die Antwort zurückkommt. Dies ist aber auch einfach asynchron mittels asyncRestTemplate möglich (Welches nur bis Spring 4 funktioniert und in Spring 5 von WebClient abgelöst wird, oje…) Somit bleibt der aktuelle Thread nicht blockiert, sondern kann weiterarbeiten und irgendwann trudelt dann die Antwort des REST Services ein.

Statt nach dem REST Call mit .get() auf die Antwort zu warten, gibt man ihm zwei Callbacks mit: Einen SuccessCallback und ein FailureCallback. Der SuccessCallback wird bei erfolgreichem Aufruf aktiviert und enthält das Ergebnis des Services. Der FailureCallback wird aufgerufen, wenn beim Aufruf des REST Services oder im Service selber eine Exception auftritt. Das Objekt, dass wir dabei für die Callbacks verwenden, ist ein ListenableFuture vom Package „org.springframework.util.concurrent“.

Macht man das ganze in einer JavaFX Applikation, muss man noch etwas bestimmtes berücksichtigen. Ich will jetzt hier aber nichts spoilern.

Aufruf des Rest Services

Der Aufruf des Services ist simpel. Wir sagen, welchen Mediatype wir verwenden, bauen uns ein AsyncRestTemplate und rufen die exchange Methode auf. In diesem Beispiel wird die Antwort ein Objekt des Typs User sein. Obwohl der REST Service JSON zurückliefert, kann uns das egal sein, da Spring die Antwort automatisch nach JSON serialisiert und in das Objekt deserialisiert. Natürlich ist es dabei von enormen Vorteil, wenn die Serverseite das gleiche Objekt/die gleiche Klasse verwendet (In diesem Beispiel die Klasse User).

String url = "http://localhost:8089/meineresturl/user/11");
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.TEXT_PLAIN);
HttpEntity request = new HttpEntity<>("params", headers);
AsyncRestTemplate asyncRestTemplate = new AsyncRestTemplate();

ListenableFuture> response = asyncRestTemplate.exchange(url, HttpMethod.GET, request,
     User.class); 

response.addCallback(successCallback, ex -> onFailure(ex)); 

Beim addCallback fällt auf, dass SuccessCallback und FailureCallback verschieden hinzugefügt werden. Das kann beliebig gemacht werden. In diesem Beispiel wurde der SuccessCallback in einer anderen Klasse erstellt (nämlich im JavaFX ViewModel, das Zugriff auf alle GUI Objekte hat) und hier hinzugefügt. So landet das Ergebnis am Ende praktischerweise in der anderen Klasse.

FailureCallback direkt in einer Methode

Der einfachere Weg, mit dem Ergebnis bzw. in diesem Fall einem Fehler umzugehen, ist es, mittels eines Lambdas direkt auf eine Methode zuweisen. In dieser Methode kann das Ergebnis wie gewünscht behandelt werden.

private void onFailure(Throwable ex) {
     LOGGER.error("Fehler beim Aufruf des Services: ", ex);
 }

Direktes Hinzufügen des SuccessCallbacks plus Wechseln in JavaFX Thread

Damit der SuccessCallback hinzugefügt werden kann, muss er irgendwo definiert werden. Wie gesagt, das kann in irgendeiner Klasse geschehen und dann der Klasse, die für den oben stehenden REST Call zuständig ist, übergeben werden.

Der Body der Response entspricht dabei dem angegebenen Objekt User und die Werte werden automatisch gesetzt. User muss dabei ein POJO mit Gettern und Settern sein, damit die Werte von Spring gesetzt werden können.

Mit .getStatusCode() kann der HTTP Statuscode abgefragt werden. Die gesamte Liste findet man auch in dieser Klasse org.springframework.http.HttpStatus.

public SuccessCallback> createDurchfahrtenSuccessCallback() {
       return response -> {
           HttpStatus httpStatusCode = response.getStatusCode();
           if (HttpStatus.NOT_FOUND.equals(httpStatusCode)) {
               LOGGER.info("HTTP Status Code 404 erhalten - Ressource nicht verfuegbar");
           } else if (HttpStatus.OK.equals(httpStatusCode)) {        
             // Wieder in den JavaFX Hauptthread gehen
             Platform.runLater(() -> {
                User user = response.getBody();
                speichereUser(user);
             });
         } else {     
            LOGGER.info("HTTP Status Code " + httpStatusCode + " erhalten"); }
         };
  }

In der Mitte des folgenden Codestücks sieht man auch den Teil, den man bei einem Aufruf aus einer JavaFX Applikation berücksichtigen muss. Die Antwort des REST Services kommt asynchron und läuft dort in irgendeinem Thread, aber nicht im JavaFX Hauptthread (der Code kann übrigens gedebuggt werden, einfach Breakpoint im Callback setzen).

Damit nun die Verarbeitung und somit der Zugriff auf die GUI Elemente klappt, muss man mittels Platform.runlater() in den JavaFX Thread wechseln, bevor man das Ergebnis verwendet.

Simulieren des REST Services in einem jUnit Test mittels WireMock

Programmiert man gleichzeitig die Client- wie auch Serverseite eines REST Services kann es durchaus vorkommen, dass der Code für den Aufruf des Services vor dem eigentlichen Service-Code fertig ist.

In diesem Fall kann man mittels des Frameworks WireMock einfach einen REST Service für Testzwecke simulieren.

Dazu erstellt man wie gewohnt einen jUnit Test und verwendet WireMock mit den gewünschten Parametern. Natürlich muss das WireMock JAR vorher noch dazugeladen werden, etwa im Maven POM File:

groupId: com.github.tomakehurst
artifactId: wiremock
version: 2.19.0
scope: test

Als erstes erstellt man eine sogeannnte WireMockRule und gibt den gewünschten Port an (dieser muss dann natürlich in der URL beim REST Service Aufruf auch drin sein).

import com.github.tomakehurst.wiremock.junit.WireMockRule;

@Rule
public WireMockRule wireMockRule = new WireMockRule(8089); 
// No-args constructor defaults to port 8080 

Das eigentliche Simulieren des REST Services geschieht dann tatsächlich in nur einer einzigen Zeile Code, in der man sagt, welchen HTTP Statustyp man zurückgeben will (200 = Alles OK), ob es in JSON sein soll und welchen Body man senden will.

String url = "/meineresturl/user/11");  // URL ohne Host

stubFor(get(urlEqualTo(url)).willReturn(aResponse().withStatus(200)
         .withHeader("Content-Type", "application/json")
         .withBody(userJson))); 

Der Body kann ein einfacher String „Hallo Welt“ sein. Ich habe in meinem Fall ein Test User erstellt, ein paar Beispielwerte reingepflanzt und dann das ganze Objekt mittels Jackson ObjectMapper von Hand serialisiert.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper; 

private String userToJson(User user) {
     String userJson = "";
     ObjectMapper mapper = new ObjectMapper();
     try {
         userJson = mapper.writeValueAsString(user);
     } catch (JsonProcessingException e) {
         e.printStackTrace();
     }
     return user;
 }

Also zuerst definiert man im jUnit Test den REST Service mit stubFor und kann dann eine Instanz des REST Service Aufrufers verwenden, um den REST Service aufzurufen. Falls es zu Beginn nicht klappt muss man sicherstellen, dass die URL, die der Service Aufrufer verwendet, wirklich 1-zu-1 mit der URL übereinstimmt, die man dem stubFor mitgibt.

Als einfacher Test kann man also zum Beispiel einen User mit Namen „Peter“ erstellen, diesen in JSON Serialisieren und dort als Body angeben. Dann rufe ich den REST Service auf, erhalte automatisch das „User“ Objekt und prüfe mit jUnit

assertEquals("Peter", user.getName());

WireMock hat noch viele weitere Möglichkeiten, um das Resultat zu verifizieren. Siehe dazu http://wiremock.org/

PS: Muss man beim REST Service Aufruf wie ganz oben beschrieben den SuccessCallback mitgeben muss man im jUnit Test natürlich auch so einen definieren, damit man das Ergebnis bearbeiten kann. Oder man verwendet beim SuccessCallback einfach auch die direkte Methode wie beim FailureCallback.

Ich musste übrigens noch einen kleinen Sleep zwischen dem Aufruf des REST Services und dem anschliessenden assertEquals einbauen, damit der jUnit Test erfolgreich war.

private void warteAufCallback() {
     try {
         Thread.sleep(100);
     } catch (InterruptedException e) {
         e.printStackTrace();
     }
 } 

So das wäre alles für heute. Ich hoffe, der Beitrag erleichtert jemandem das Leben 🙂