CRUD Methods - Standardize and Refactor

[MatthewBlam]

Description

Great work on the backend issues last sprint! Due to the nature of splitting up the work, our backend CRUD route handlers slightly differ in style and behavior (Supabase response handling, error formatting, [id] slug conventions, and null/empty GET responses). This may create inconsistent API responses for the frontend, increasing debugging time, and makes future maintenance/refactors harder.

This issue standardizes and refactors our CRUD methods so all routes follow the same conventions and response shapes.

Notes

• Make sure to run git pull before any development work
• Complete your development in a new branch
• Link this issue to your PR
• Feel free to reach out if you have any questions!

Acceptance Criteria

• All backend CRUD route handlers use a consistent pattern for:
  • Supabase response destructuring
  • NextResponse data + error formatting
  • [id] slug param access
  • GET behavior for missing/empty data
  • Removal of debug logs and deprecated helpers
• Routes pass existing tests (or have tests updated accordingly) and do not introduce console noise.

Task

• Supabase response destructuring

  • Update all Supabase calls to destructure only required fields (e.g. data, error) instead of using the full response object.

• Standardize NextResponse formatting

  • For Supabase errors:
    • Use:
      • const status = postgrestErrorToHttpStatus(error);
      • NextResponse.json({ error: error }, { status: status })
  • For server errors (outside Supabase errors, in a catch clause):
    • Use:
      • NextResponse.json({ message: "Internal Server Error" }, { status: 500 })
  • For successful data responses:
    • Use:
      • NextResponse.json({ data: data }, { status: 200 })

• Standardize [id] slug param usage

  • In all methods for [id] slug routes, access params via:
    • const { id } = await params;

• GET behavior rules

  • For GET methods on [id] slug routes:
    • Ensure the Supabase query uses .single()
  • For other GET methods (non-[id] routes):
    • Return 404 Not Found when data is:
      • null, or
      • an empty array []

• Clean up noise and dead code

  • Remove unnecessary console.log / console.error statements (good during local testing, but should not ship).
  • Remove deprecated or unused helper functions to keep route files uncluttered.

• Consistent documentation across all methods

  • Add/update method docstrings for each CRUD handler to consistently describe:
    • Purpose of the route
    • Expected inputs (params/body)
    • Response shape ({ data } or { error } / { message }) and status codes
    • Any special cases (e.g., 404 on empty results)
  • For more info, see David's request for this in Standardize documentation for crud methods #24

Additional Information

• This is a refactor/standardization pass: avoid changing business logic unless required to meet the conventions above.
• Apply consistently across all CRUD route handlers (GET/POST/DELETE where applicable).