Join the GitHub Classroom assignment for this lab by navigating to https://classroom.github.com/a/J57q9KLQ

Clone the repository for the GitHub Classroom assignment to your local machine

Open the repository in IntelliJ

https://www.jetbrains.com/help/idea/import-project-or-module-wizard.html#open-project

Make sure the Java SDK for the project is configured

https://www.jetbrains.com/help/idea/sdk.html#set-up-jdk

Build the Docker containers for the lab and start Docker Compose via the command line

cd scripts ./start-container

on Windows machines, run start-container.bat instead

This command might take some time as the prerequisite software is downloaded and built. If everything works as expected, you should see output showing that the containers have started, which is when you'll know this step is complete!

NOTE: The start-container script will continue to run until you press CTRL+C. You will need to use a dedicated terminal to run this script each time you work on your project throughout the class. Future steps in this lab that require the command-line will need to be executed in a new terminal!

When you press CTRL+C on Windows you will be asked a question "Terminate batch job (Y/N)?". Answer NO (N/n) to the question.

Attach to the runtime Docker container via the command line

 ./attach-container

on Windows machines, run attach-container.bat instead

The attach-container script will run a bash shell inside the swdev-springboot Docker container that you started in step 4. You should see a prompt similar to this one to know that the command succeeded:

root@0343d47d952f /app/swdev

NOTE: You can run the attach-container script as many times as you'd like in new terminal windows to create separate bash shells inside the swdev-springboot Docker container.

NOTE: all of the command line steps after this one will be completed inside the bash prompt created by the attach-container command

Run the Spring Boot application to test by executing the following command:

mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005"

NOTE: You will need to stop (CTRL+C) and restart the application each time you make a change so it can be rebuilt

NOTE: When you start up your project you will have access to a completely working solution for Lab 04: RESTful POST/PUT/DELETE Using Spring Boot. Be sure to review the controller class and associated tests for guidelines about how to complete this project!

Cities:Implement the necessary methods to provide CRUD operations for cities inside src/main/java/edu/msudenver/city/CityController.java. This will also require you to create a City entity class, a CityRepository class, and a CityService class. The URL prefix should be /cities.

NOTE: You will have to manage the foreign key between city and country using the correct annotations as noted in our lecture about JPA

In your City entity class, you need to map the relationship between City and Country. You do not need to map the reverse relationship from Country to City.

Create unit tests for each HTTP method of your CityController class and their corresponding methods in the CityService class, similar to the tests for CountryController and CountryService. In your unit tests you should verify each success and error status code. The controller unit tests should go into the folder src/test/java/edu/msudenver/city/CityControllerTest.java and the service unit tests should go into src/test/java/edu/msudenver/city/CityServiceTest.java

Once your /cities API is working and testing correctly on your local machine, deploy your updates to Heroku. Use the same application you created in Lab 05: Deploying a RESTful Spring Boot application to Heroku.

Screenshot each Postman test for POST / GET one / GET all / PUT / DELETE to your Heroku-deployed application, and save each request to the 7dbs collection we modified in lab04.

Venues:Implement the necessary methods to provide CRUD operations for venues inside src/main/java/edu/msudenver/venue/VenueController.java. This will also require you to create a Venue entity class, a VenueRepository class, and a VenueService class. The URL prefix should be /venues.

NOTE: You will have to manage the foreign key between venue and city using the correct annotations as noted in our lecture about JPA

In your Venue entity class, you need to map the relationship between Venue and City. You do not need to map the reverse relationship from City to Venue.

Create unit tests for each HTTP method of your VenueController class and their corresponding methods in the VenueService class, similar to the tests for CountryController and CountryService. In your unit tests you should verify each success and error status code. The controller unit tests should go into the folder src/test/java/edu/msudenver/venue/VenueControllerTest.java and the service unit tests should go into src/test/java/edu/msudenver/venue/VenueServiceTest.java

Once your /venues API is working and testing correctly on your local machine, deploy your updates to Heroku. Use the same application you created in Lab 05: Deploying a RESTful Spring Boot application to Heroku.

Screenshot each Postman test for POST / GET one / GET all / PUT / DELETE to your Heroku-deployed application and save each request to the 7dbs collection we modified in lab04.

Events:Implement the necessary methods to provide CRUD operations for events inside src/main/java/edu/msudenver/event/EventController.java. This will also require you to create an Event entity class, an EventRepository class, and a EventService class. The URL prefix should be /events.

NOTE: You will have to manage the foreign key between Event and Venue using the correct annotations as noted in our lecture about JPA

In your Event entity class, you need to map the relationship between Event and Venue. You do not need to map the reverse relationship from Venue to Event.

Create unit tests for each HTTP method of your EventController class and their corresponding methods in the EventService class, similar to the tests for CountryController and CountryService. In your unit tests you should verify each success and error status code. The controller unit tests should go into the folder src/test/java/edu/msudenver/event/EventControllerTest.java and the service unit tests should go into src/test/java/edu/msudenver/event/EventServiceTest.java

Once your /events API is working and testing correctly on your local machine, deploy your updates to Heroku. Use the same application you created in Lab 05: Deploying a RESTful Spring Boot application to Heroku.

Screenshot each Postman test for POST / GET one / GET all / PUT / DELETE to your Heroku-deployed application and save each request to the 7dbs collection we modified in lab04.

NOTE: The requirements for functionality, including required response body and response code for each HTTP Method (GET all / GET one / PUT / POST / DELETE) are the same as lab 04.

GET requests should respond with 200 and return the object if found, and respond with 404 and no response body if not found

POST requests should respond with 201 and return the newly created object if successful, and return 400 with no response body if not found

PUT requests should respond with 200 if the object exists and was updated successfully. If the object does not exist, a 404 is returned with no response body. If there is an error updating the object, a 400 is returned with no response body

DELETE requests should return 204 with no response body if the deletion is successful. A 404 is returned if the object does not exist, with no response body

Export your Postman collection to a JSON file that replaces the existing one inside the scripts/postman folder

As we noted in class, a microservice that only provides CRUD operations does not have sufficient responsibility to be useful. Now that we have the basic functionality for country, city, venue, and event implemented in our API, I would like you to think about the guidelines for designing a microservice, and the guidelines for decomposing a business problem, that we discussed in Lecture 12 - Introduction to Microservices.pptx Download Lecture 12 - Introduction to Microservices.pptx.

What additional operations should be added to the events microservice to give it value? What additional operations on countries, cities, venues, and events would make the microservice add to the system's functionality beyond just providing access to the database?

Describe the business case for the events microservice, what operations needs to be supported, and the data model that it supports.

Do you believe that one microservice, the one that we have created here, is correctly scoped for the four database tables that we are using?

Is the event microservice "right sized" for its business case? Now that you have thought about additional operations for the service, and examined the data model, should we break the microservice down into smaller pieces, or do you believe it to be correct the way it is?

NOTE: When I say our "event microservice" I am not just talking about the Event controller! All of the files we have created for country, city, venue, and event are working together to create a microservice that allows us to reserve events. So when you are discussing the scope of the microservice in this document, please make sure to think about the service in terms of all of its functionality, and not just the event controller.