CSE 341: Web Services

W02 Assignment: Part 2 - Create the Plan

Overview

• Purpose: Complete the assigned portion of this week's project.
• Task: Follow the instructions below and submit the required work.

In this part of the assignment, you will convert your two Week 02 feature specs into GitHub issues. In Week 01 the assignment provided the exact issue text to use. This week, you will write more of the issue details yourself.

Defining Good Tasks

A good GitHub issue is focused, specific, and verifiable. Each issue should describe one clear piece of work, include the route names or files likely affected, and include a Test Plan that proves the work is complete.

Activity Instructions

Review your spec

Before creating issues, review both feature specs from spec-week02.md. You will be implementing CRUD operations for both books and authors, along with the relationships between them.

Create GitHub issues

Create the following issues in GitHub for the Week 02 work. The issue titles are provided for you, but you will add the description, Test Plan, and the details from your spec.

Issue list

1. Update Book Collection to reference authors and finish Book API.
2. Implement Author Collection and API.

Each of these issues should include creating the Swagger documentation and testing all routes both locally and in the deployed application.

For each issue, write:

• A clear title.
• A short description of the work.
• The Spec for the feature. (You can copy and paste this from the previous step.)
• A Test Plan with specific checks.

Use this issue template

You may copy this template into each GitHub issue and fill in the details from your spec.

# Issue Title

## Description
-

## Spec
-

## Test Plan
-

Create Issue 1: Update Book Collection to reference authors and finish Book API

For the first issue, you may use the complete issue text below.

# Update Book Collection to reference authors and finish Book API

## Description
- Update the existing Week 01 book API so book documents include a reference to an author.
- Add the remaining CRUD operations for books.
- Validate book request bodies before writing to MongoDB.
- Validate that each submitted `authorId` matches an existing author document.
- Add Swagger documentation for all book routes.
- Test the book routes locally and in the deployed Render application.

## Spec
### Goal
Update the existing Week 01 book API so book documents include a reference to an author and the API supports all CRUD operations for books. Every book route must be documented and testable in Swagger.

### Data Model
Book documents will be stored in the `books` collection.

Required book fields:
- `id`: string, required, custom id such as `b1`
- `authorId`: string, required, references the `id` field of an author document
- `title`: string, required
- `publicationDate`: string, required

Books will continue to use custom string ids instead of MongoDB `_id` values for route parameters.

### Relationship to Authors
Each book will identify its author with an `authorId` field. The value of `authorId` must match the custom `id` value of an existing author document.

When creating or updating a book, the API should reject the request with a `400` status code if the submitted `authorId` does not match an existing author.

### Routes

#### GET /books
Purpose: Return all books.

Success:
- Status code: `200`
- Response body: an array of book objects

Errors:
- `500` if an unexpected server or database error occurs

#### GET /books/:id
Purpose: Return one book by its custom id.

Success:
- Status code: `200`
- Response body: the matching book object

Errors:
- `404` if no book exists with that id
- `500` if an unexpected server or database error occurs

#### POST /books
Purpose: Create a new book.

Request body:

    {
      "id": "b4",
      "authorId": "a1",
      "title": "Example Book Title",
      "publicationDate": "2026-01-15"
    }

Success:
- Status code: `201`
- Response body: the newly created book object

Errors:
- `400` if a required field is missing
- `400` if the `id` already exists
- `400` if the `authorId` does not match an existing author
- `500` if an unexpected server or database error occurs

#### PUT /books/:id
Purpose: Update an existing book.

Request body:

    {
      "authorId": "a2",
      "title": "Updated Book Title",
      "publicationDate": "2026-02-20"
    }

Success:
- Status code: `200`
- Response body: the updated book object

Errors:
- `400` if a required field is missing
- `400` if the `authorId` does not match an existing author
- `404` if no book exists with that id
- `500` if an unexpected server or database error occurs

#### DELETE /books/:id
Purpose: Delete an existing book.

Success:
- Status code: `204`
- Response body: none

Errors:
- `404` if no book exists with that id
- `500` if an unexpected server or database error occurs

### Swagger Documentation
Swagger must document every book route.

### Deployment Expectations
After implementation, the book routes must work locally and from the deployed Render application. The deployed Swagger page at `/api-docs` must allow someone to test every book route from the browser.

## Test Plan
- Existing `GET /books` responses include `authorId`.
- Existing `GET /books/:id` responses include `authorId`.
- `POST /books` creates a book and returns status 201.
- `POST /books` returns 400 when required fields are missing.
- `POST /books` returns 400 when `authorId` does not match an existing author.
- `PUT /books/:id` updates an existing book.
- `PUT /books/:id` returns 400 when `authorId` does not match an existing author.
- `PUT /books/:id` returns 404 when the book does not exist.
- `DELETE /books/:id` deletes an existing book.
- `DELETE /books/:id` returns 404 when the book does not exist.
- All book routes are documented in Swagger.
- All book routes can be tested locally from `/api-docs`.
- All book routes can be tested from the deployed Render `/api-docs` page.

Create Issue 2: Implement Author Collection and API

For the second issue, use the headings below and fill in the details from your own spec. You can copy your author feature spec from Part 1 into the Spec section.

# Implement Author Collection and API

## Description
-

## Spec
-

## Test Plan
-

Check the quality of your plan

After the issues are created, review them with these questions:

• Does every required behavior in your feature specs have at least one issue that supports it?
• Can each issue be verified through Swagger, MongoDB Atlas Data Explorer, Render, or GitHub?
• Did you include the book authorId relationship and the author deletion behavior from your spec?
• Did you include documentation and deployment as explicit work?
• Could another developer understand what to do from each issue?
• Could another developer implement each issue without reading your mind?

Deliverables Checklist

• Your GitHub repository has Week 02 issues for the planned work.
• Each issue includes a Test Plan.
• Your issues cover the books feature spec, the authors feature spec, Swagger, and deployment.

Next Step

Continue to Part 3 - Implement the Plan.

Other Links:

• Return to: Week Overview | Course Home