Chapter 8 Lab

Handling Requests

You've just been shown how to write a simple "Hello World" Spring MVC project. The labs in this Chapter will help you understand the basic components in a Spring MVC project.

Instructions

Lab 1

1. Start be re-mapping the heartbeat controller and its only method so that we can add more controllers and more methods down the line. Map HeartbeatController to /heartbeat and the existing "Hello, world" service should be mapped to get.

• Implement a service mapped to reverse in HeartbeatController. The service will have one query parameter of type String and return type Message. The object returned is simply the input string with the characters in reverse order.
  • Write the unit Test for the method described above.
  • Write the implementation for this method.
• Implement a service mapped to toUpper in HeartbeatController. The service will have utilize the HTTP request body whose type should be mapped to Message. The object returned is another Message with the value of that message being the input string with the characters all converted to upper case.
  • Write the unit Test for the method described above.
  • Write the implementation for this method.

Lab 2

1. Create a new Pokemon controller following similar patterns to the heartbeat controller. The controller should have one endpoint mapped to /pokemon/get with the GET verb and a single path variable at the end of the path which is used for the ID of the Pokemon. The endpoint should query the database and return the appropriate Pokemon object for the requested ID.

Lab 3

Add remaining crud operations to the controller.

1. Implement the create service. Its path should be /pokemon/create, it should utilize the POST verb and accept a JSON object in its request body with two integer properties: hp, and attack. The service should return a complete Pokemon object.
   • Create a new POJO named PokemonCreateRequest which stores the HP and attack each as type Integer. Common practice is to put such objects in a new package named pojo or dto (I personally prefer pojo).
   • Write a test case for the create method. It will take a parameter PokemonCreateRequest and will return type Pokemon.
   • Implement the create method as described above.

• Implement the delete method. It should be mapped to /pokemon/delete with the POST verb and should utilize a single path variable at the end of the path to describe the Pokemon to delete. Its response body should be empty.
• Implement the update method. It should be mapped to /pokemon/update with the POST verb, it should not have any path or query parameters and it should accept a response body in JSON form with three properties (all integers): id, hp, and attack. It should have an empty response body. Invoking this service should should update the HP and attack of the Pokemon with the provided ID.
  • Create a new POJO named PokemonUpdateRequest which stores the ID, HP, and attack. Common practice is to put such objects in a new package named pojo or dto (I personally prefer pojo).

We recommend creating new POJOs (as opposed to re-using Pokemon) because request methods such as these have changed frequently in the past, and you might find yourself changing these in future labs too...