Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Purpose
Implement a Web Application and RESTful HTTP API to do CRUD operations on sprites in the
Sprite Game domain discussed in class. Using the code of the Sprite Case Study demonstrated
in class as a starting point, implement a new application with a proper set of JSF pages to do
CRUD operations on Sprites, and implement an HTTP RESTful interface as specified below.
Requirements
Architecture: You must maintain the Sprite Case Study tiered architecture, which is similar to
the architecture of the Address Book example project studied in class (presentation layer with
JSF pages and a named managed bean, a business layer with an Enterprise Session bean façade,
and a data layer including an SQL database engine and database schema).
Packaging: The project must be organized in the same way as the Sprite Case Study, which is a
Enterprise Application project with a Web (war) sub-project and an EJB sub-project. All EJBs in
the project must reside in the EJB sub-project, so the Web sub-project will contain just JSF
pages, and their associated Named Bean controller class.
Features:
1. Implement manipulation of Sprites through JSF, including changing color using a
converter class that converts Color objects to strings and back. You can use any format
for your strings. For example, HEX color codes are appropriate: #RRGGBB, as are
decimal RGB codes: [rrr,ggg,bbb]
2. Implement appropriate data Validation on JSF manipulations (for example, does it makes
sense for the x-position of a sprite be negative?)
3. Implement a Restful HTTP Interface capable of CRUD operations on Sprites:
a. Each response from your API should include an appropriate HTTP response code:
(501, 404, 201, 204, …)
b. Supply an endpoint that can be used to determine how many sprites are in the
database
c. POST on a specific id should update the Sprite having that id with the new nonnull information given by the Sprite in the body of the request
i. It’s an error if the id doesn’t exist, or if the Sprite in the body has a nonmatching id
ii. Old values should be preserved if they are not overwritten by the new
changes. Consider adding a method to the Sprite class so that the method
can be called on the old Sprite with a new Sprite as an argument. Perhaps
newSprite.updates(oldSprite), updates the old Sprite with all
the non-null new Sprite values
d. PUT on a specific id should replace the Sprite having that id with the Sprite in the
body of the request.
i. It is an invalid request if the Sprite with that id doesn’t exist, or if the
Sprite in the body has a non-matching id
ii. The old Sprite is replaced by the new Sprite, so only the new values should
remain in the result that is stored in the database.
e. PUT on the root resource (sprite table) is not supported
f. POST on the root resource (sprite table)
i. Accepts a Sprite in the body of the request
1. Creates the new sprite if id is null
2. Updates an existing sprite if id is not null and exists
a. Be sure that new non-null attribute values overwrite old
values, and old values that are not overwritten are
preserved
3. It is an invalid req