Ensure all attendance-related API endpoints follow RESTful conventions

[pa19duxu]

The current API endpoints for attendances deviate from RESTful standards in several places. This ticket aims to align all attendance endpoints with strict REST principles.

Goals:

1. Use standard HTTP status codes

   • Return 201 Created on successful POST
   • Include Location header pointing to the new resource (e.g. /api/attendances/{id})
   • Use 200 OK, 204 No Content, 400 Bad Request, etc. where appropriate

2. Remove non-standard response wrappers

   • Eliminate custom message-based wrappers like { message: "...", data: ... }
   • Return plain resources or standardized error formats (e.g. RFC 7807 ProblemDetails)

3. Correct use of HTTP methods

   • GET /api/attendances → Fetch all attendances (optionally with filters, pagination, sorting)
   • GET /api/attendances/{id} → Fetch a single attendance
   • POST /api/attendances → Create a new attendance
   • PUT /api/attendances/{id} → Full update
   • PATCH /api/attendances/{id} → Partial update
   • DELETE /api/attendances/{id} → Delete attendance

4. Consistent URL structure

   • Use plural, noun-based routes (e.g. /api/attendances)
   • Avoid action-based verbs in routes (e.g. no /api/createAttendance)

5. Dynamic Location header

   • After POST, return a Location header with the GET URL for the created attendance (e.g. /api/attendances/{id})
   • Use attribute routing or reflection to construct the URL dynamically if necessary