Finally, we should also note how this move to the API Gateway and a new UI model influenced the implementation of our application service. While our goal is to minimize changes to the monolith code, the interaction between the client and the monolith did change from an MVC model to a REST-based API. That meant that the controller portion of our MVC needed to be refactored to expose the REST API that is invoked through the API Gateway.
To view these changes, navigate to the Cloud9 services in the AWS console and open the IDE for this workshop. In the left-hand pane, open the “lab2/server/src/main/java” folder. This will open a series of folders that correspond to the Java package naming. Under the “saasfactory” folder you’ll see an “api” folder that holds the new REST API for our services. Double-click on the “Products.java” file to open the API in the editor. The following is a snippet of code from this file:
@CrossOrigin
@GetMapping(path = "/products/{id}")
public Product getProduct(@PathVariable Integer id) throws Exception {
logger.info("Products::getProduct id = " + id);
return productService.getProduct(id);
}
@CrossOrigin
@GetMapping(path = "/products")
public List<Product> getProducts() throws Exception {
logger.info("Products::getProducts");
return productService.getProducts();
}While this code does have similarities to the code from our controller, you’ll notice here that we’ve introduced annotations that declare our REST API entry points. This API now returns JSON strings to the client which now assumes responsibility for rendering the HTML.