Issue Description
Two endorsement-related endpoints (GET and POST) are currently defined under the skills controller, which should be in endorsement controller. These routes should be moved under /v1/endorsements to maintain clear and consistent resource boundaries.
Current Behavior
-
The API exposes two endorsement-related endpoints under the skills resource:
GET /v1/skills/{id}/endorsements
POST /v1/skills/{id}/endorsements
-
This design implies that endorsements are strictly tied to the skills resource. But a separate route PATCH /v1/endorsements/{id} already exists under the endorsements resource. This causes inconsistency in routing structure.
Expected Behavior
- All endorsement-related actions should be grouped under
/v1/endorsements.
- Specifically,
GET /v1/skills/{id}/endorsements and POST /v1/skills/{id}/endorsements.
Steps to Reproduce
- Look at the current route definitions in the skill controller.
- Notice endorsement-related logic defined under the skills controller.
- Compare this with
PATCH /v1/endorsements/{id}, which is defined under the endorsement controller.
Screenshots
Severity/Priority
Checklist
Issue Description
Two endorsement-related endpoints (GET and POST) are currently defined under the skills controller, which should be in endorsement controller. These routes should be moved under /v1/endorsements to maintain clear and consistent resource boundaries.
Current Behavior
The API exposes two endorsement-related endpoints under the
skillsresource:GET /v1/skills/{id}/endorsementsPOST /v1/skills/{id}/endorsementsThis design implies that endorsements are strictly tied to the
skillsresource. But a separate routePATCH /v1/endorsements/{id}already exists under theendorsementsresource. This causes inconsistency in routing structure.Expected Behavior
/v1/endorsements.GET /v1/skills/{id}/endorsementsandPOST /v1/skills/{id}/endorsements.Steps to Reproduce
PATCH /v1/endorsements/{id}, which is defined under the endorsement controller.Screenshots
Severity/Priority
Checklist