Module CSC5002—ASR6: Middleware and software architecture for distributed applications

In the next Figure, we display an abstract view of the sequence of a REST call: the client requests a given REST endpoint, and then the REST server forwards the request to the appropriate REST resource, which calls the corresponding method of the Façade.

You can check to make sure you have a good understanding of the sequence shown in the sequence diagram.

When writing a class that models a REST resource, we often wonder how to access the Façade to delegate processing to the application's business logic. We provide the following abtract class, from which all REST resource classes inherit. Method setApplicationFacade is the method that is called by class that instantiate the Façade and that “starts” the system.

You can create this class in your Maven project: at first glance and for now, in minisocs-frontend.hexagon.

In next question, we create the REST resource classes, which extends class AbstractResource.

As a reminder, the methods of the façade take as inputs and outputs JAVA records, and class UtilSerialiser provides methods to serialise and de-serialise these records. Therefore, REST resource can simply consume and produce “plain text” strings.

The methods of the endpoints are organised around a call to UtilSerialiser::readValue, a call with accessApplicationFacade() to perform the delegation to the mehod of the façade, and a call to return the response, which potentially contains an entity for the outputs. The last instruction is then similar to either return Response.status(Status.OK).build(); or return Response.status(Status.OK).entity(UtilSerialiser.writeValueAsString(returnValue)).build();. Of course, you must manage exceptional cases.

Create REST resources classes (one or several classes) in order to implement the mehods for the first three use cases. This or these classes should extend class AbstractResource.

To test REST resources, you can either follow the procedure shown in the examples provided in the Discovery Lab—by incorporating everything into the JUnit test class—or create a separate REST server class before creating the JUnit test class.

For the first option, displayed in Figure 2, everything in the JUnit test class, the method annotated @BeforeEach registers the REST resources, creates and start the Grizzly HTTP server, and then creates the HTTP client for the test. Then, the method @AfterEach closes and shutdown everything. Finally, a method annotated @Test can mimick the scenario in the MiniSocs test class TestScenario with a sequence of calls for creating users, social networks, and posting messages.

By using JAVA records, the client code for calling a MiniSocs endpoint typically looks like the following (restService is the WebTarget of the REST client used to access the REST server, and we have added a simple check on the response status):

For the second version, start by creating a class that implements a REST server, such as RestServer. Put this class in the src/main/java directory structure. Its constructor can handle registering the REST resources and creating the Grizzly HTTP server. Its start and shutdown methods can then be used to start and stop the HTTP server. Next, proceed with building the JUnit test class, but this time by instantiating your REST server class.

Awaitility.await().until(() -> {
  try {
    var response = restService.path("/isready").request().get();
    Assertions.assertEquals(Response.Status.OK.getStatusCode(), response.getStatus());
    var ok = response.readEntity(String.class);
    return ok.equals("isready");
  } catch (Exception ex) {
    return false;
  }
});