Try   HackMD

02 FinalProject: Build the Backend System for a Car Website

tags: Udacity

01 Introduction

Project Introduction
In this project, you'll use your skills with Spring Boot, APIs, documentation and testing to implement a Vehicles API that serves as an endpoint to track vehicle inventory. While the primary Vehicles API will perform CRUD operations (Create, Read, Update and Delete) related to vehicle details like make, model, color, etc., it will need to consume data from other APIs as well regarding location and pricing data. You will implement a RESTful API for the Vehicles API, as well as converting a Pricing Service API to a microservice.

By the end of this project, you'll have an application that can communicate with other services and be able to be viewed and used through Swagger-based API documentation.

Over the next several pages, we'll do a brief overview of the code for each application involved in the project, and then the instructions for the project itself. You are welcome to skip the code overview sections if you want to dive straight into the project instructions. You can obtain the project code here.

02 Location Service Code

Location Service Code (Boogle Maps)
You'll find the code related to our location service in the boogle-maps folder. It serves as a Mock to simulate a Maps WebService where, given a latitude and longitude, will return a random address.

You won't have to implement anything as part of this application, but let's take a quick look through the included files. Note that every package is within com.udacity, so we won't include that part of the package name below.

boogle.maps
Address
This declares the Address class, primarily just made of the private variables address, city, state and zip. Note that the latitude and longitude are not stored here

  • they come from the Vehicles API.

BoogleMapsApplication
This launches Boogle Maps as a Spring Boot application.

MapsController
This is our actual REST controller for the application. This implements what a GET request will respond with - in our case, since it is a Mock of a WebService, we are just responding with a random address from the repository.

MockAddressRepository
Repositories normally provide some type of data persistence while the web service runs. In this case, this Mock is simply choosing a random address from the ADDRESSES array defined in the file.

03 Pricing Service Code

Pricing Service Code
You'll find the code related to our pricing service in the pricing-service folder. It serves as a REST WebService that simulates a backend to store and retrieve the price of a given vehicle. In the project, you will convert it to be a microservice registered through a Eureka server.

Let's take a quick look through the included files, only certain files of which you will need to implement. Note that every package is within com.udacity, so we won't include that part of the package name below.

pricing
PricingServiceApplication
This launches the Pricing Service as a Spring Boot application.

pricing.api
PricingController
This is our actual REST controller for the application. This implements what a GET request will respond with

  • in this case, a randomly generated price gathered from the PricingService. Once converted to a microservice, the Controller should not be explicitly necessary.

pricing.domain.price
Price
This declares the Price class, primarily just made of the private variables currency, price and vehicleId.

PriceRepository
This repository provide a type of data persistence while the web service runs, namely the ID->price pairing generated by the PricingService.

pricing.service
PriceException
This creates a PriceException that can be thrown when an issue arises in the PricingService.

PricingService
The Pricing Service does most of the legwork of the code. Here, it creates a mapping of random prices to IDs, as well as the method (in our mock service here) to generate the random prices. Once converted to a microservice, the Service should not be explicitly necessary.

04 Vehicles API Code

Vehicles API
You'll find the code related to our Vehicles API in the vehicles-api folder. It serves as a REST API to maintain vehicle data and to provide a complete view of vehicle details including price and address (obtained from the location and pricing services).

Let's take a quick look through the included files - and don't worry, you won't need to implement every single one of these! Note that every package is within com.udacity, so we won't include that part of the package name below.

vehicles
VehiclesApiApplication
This launches the Vehicles API as a Spring Boot application. Additionally, it initializes a few car manufacturers to place in the ManufacturerRepository, as well as creating the web clients to connect to the Maps and Pricing services.

vehicles.api
API Error
Declares a few quick methods to return errors and other messages from the Vehicles API.

CarController
This is our actual REST controller for the application. This implements what happens when GET, POST, PUT and DELETE requests are received (using methods in the CarService), and how they are responded to (including formatting with CarResourceAssembler). You will implement these methods in your code.

CarResourceAssembler
This helps mapping the CarController to the Car class to help return the API response.

ErrorController
This helps to handle any invalid arguments fed to the API.

vehicles.client.maps
Address
Very similar to the Address file for boogle-maps, this declares a class for use with the MapsClient.

MapsClient
Handles the format of a GET request to the boogle-maps WebClient to get location data.

vehicles.client.prices
Price
Very similar to the Price file for pricing-service, this declares a class for use with the PriceClient.

PriceClient
Handles the format of a GET request to the pricing-service WebClient to get pricing data.

vehicles.domain
Condition
This enumerates the available values for the condition of a car (New or Used).

Location
This declares information about the location of a vehicle. This is not the exact same as the Address class used by boogle-maps - it's primary use is related to the storage of latitude and longitude values. Because the data, such as address, gathered from boogle-maps is annotated as @Transient, this data is not stored until the next time boogle-maps is called.

vehicles.domain.car
Car
This declares certain information about a given vehicle, mostly that more about the car entry itself (such as CreatedAt). Note that a separate class, Details, also stores additional details about the car that is more specific to things like make, color and model. Note that similar to Location with data like address, this uses a @Transient tag with price, meaning the Pricing Service must be called each time a price is desired.

CarRepository
This repository provide a type of data persistence while the web service runs, primarily related to vehicle information received in the CarService.

Details
Declares additional vehicle details, primarily about the car build itself, such as fuelType and mileage.

vehicles.domain.manufacturer
Manufacturer
This declares the Manufacturer class, primarily just made of a ID code and name of manufacturer.

ManufacturerRepository
This repository provide a type of data persistence while the web service runs, primarily to store manufacturer information like that initialized in VehiclesApiApplication.

vehicles.domain
CarNotFoundException
This creates a CarNotFoundException that can be thrown when an issue arises in the CarService.

CarService
The Car Service does a lot of the legwork of the code. It can gather either the entire list of vehicles or just a single vehicle by ID (including calls to the maps and pricing web clients). It can also save updated vehicle information. Lastly, it can delete an existing car. All of these are called by the CarController based on queries to the REST API. You will implement most of these methods yourself.

test/../vehicles.api
CarControllerTest
Here, the various methods performed by the CarController are performed by creating mock calls to the Vehicles API. You will implement some of these methods yourself for great practice in building your own tests.

05 Instructions

Vehicles API Instructions
In this project you will have the opportunity to create a REST-based Vehicles API that communicates with a location and pricing service using Spring Boot, along with converting the existing Pricing Service API to a microservice registered on a Eureka server. Follow the README and code instructions and make sure to check the rubric to ensure you have completed all items.

Convert the Pricing Service
Convert the Pricing Service to a microservice, registered on a Eureka server. Also, add an additional test for the microservice.

Implement the Vehicles API
Implement all TODOs for the CarService and CarController.

Test and Document the Vehicles API

  • Add tests for the CarController class
  • Use Swagger to implement API documentation for the Vehicles API

Run the applications
Note that the Boogle Maps, Pricing Service and Vehicles API applications must all be running for all operations to perform correctly, although they should be able to launch on their own.

You can either use these in separate windows in your favorite IDE, or use the below commands:

  1. $ mvn clean package (run this in each directory containing the separate applications)
  2. Boogle Maps: $ java -jar target/boogle-maps-0.0.1-SNAPSHOT.jar
    • The service is available by default on port 9191. You can check it on the command line by using $ curl http://localhost:9191/maps\?lat\=20.0\&lon\=30.0
  3. Pricing Service: $ java -jar target/pricing-service-0.0.1-SNAPSHOT.jar
  4. Vehicles API: $ java -jar target/vehicles-api-0.0.1-SNAPSHOT.jar

06 Build the Backend System for a Car Website

Build the Backend System for a Car Website
In this project you will have the opportunity to create a REST-based Vehicles API that communicates with a location and pricing service using Spring Boot, along with converting the existing Pricing Service API to a microservice registered on a Eureka server.

Follow the README and code instructions and make sure to check the rubric to ensure you have completed all items.

Instructions

Convert the Pricing Service
Convert the Pricing Service to a microservice, registered on a Eureka server. Also, add an additional test for the microservice.

Implement the Vehicles API
Implement all TODOs for the CarService and CarController.

Test and Document the Vehicles API

  • Add tests for the CarController class
  • Use Swagger to implement API documentation for the Vehicles API

Run the applications
Note that the Boogle Maps, Pricing Service and Vehicles API applications must all be running for all operations to perform correctly, although they should be able to launch on their own.

You can either use these in separate windows in your favorite IDE, or use the below commands:

  1. $ mvn clean package (run this in each directory containing the separate applications)
  2. Boogle Maps: $ java -jar target/boogle-maps-0.0.1-SNAPSHOT.jar
    • The service is available by default on port 9191. You can check it on the command line by using $ curl http://localhost:9191/maps\?lat\=20.0\&lon\=30.0
    • 機掰: 使用curl一訂要加冒號!!
    • 更正$ curl "http://localhost:9191/maps?lat=20.0&lon=30.0"
  3. Pricing Service: $ java -jar target/pricing-service-0.0.1-SNAPSHOT.jar
  4. Vehicles API: $ java -jar target/vehicles-api-0.0.1-SNAPSHOT.jar

參考:https://knowledge.udacity.com/questions/288049

作業需求



Shannon作業參考

參考: https://github.com/ShannonHung/EurekaAndMicroService.git