Skip to content

feat: axim api improvements#38755

Open
Faraz32123 wants to merge 8 commits into
masterfrom
feat/axim-api_improvements
Open

feat: axim api improvements#38755
Faraz32123 wants to merge 8 commits into
masterfrom
feat/axim-api_improvements

Conversation

@Faraz32123

@Faraz32123 Faraz32123 commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

Summary

This PR applies a set of API standardization ADRs (0025–0029) to a batch of
contentstore endpoints, introducing new versioned API endpoints rather than
modifying existing ones.

ADRs applied: see related ADR PR #38738

Why new API versions instead of updating existing endpoints?

The ADRs mandate structural changes that are breaking for existing consumers:

  • ADR 0029 (standardized error envelope): Changes the error response format
    from the legacy {"developer_message": ..., "error_code": ...} shape to a
    structured RFC 7807 envelope (type, title, status, detail, instance).
    Any client that parses error responses from the existing endpoint would break.

  • ADR 0028 (ViewSet + DefaultRouter): Replaces APIView with a ViewSet
    registered via DefaultRouter, which generates slightly different URL patterns
    (trailing slash, router-managed routing). Existing URL patterns and named routes
    are preserved in the old version.

  • ADR 0026 (explicit auth classes): Standardizes authentication — removes
    deprecated BearerAuthentication. While not strictly breaking for JWT/session
    clients, Bearer-only consumers would lose access.

Introducing new versions allows existing consumers to stay on the current
endpoint and migrate on their own timeline, rather than absorbing a silent
breaking change.

Changes in this PR

Old endpoint New endpoint Change
GET/POST /api/contentstore/v0/xblock/ GET/POST/PATCH/DELETE /api/contentstore/v1/xblock/{usage_key}/ ADRs 0025–0029
GET /api/contentstore/v1/home/ GET /api/contentstore/v3/home/ ADRs 0025–0029
GET /api/contentstore/v2/home/ GET /api/contentstore/v4/home/ ADRs 0025–0029
GET/PUT /api/contentstore/v1/course_details/{id}/ GET/PUT /api/contentstore/v3/course_details/{course_key}/ ADRs 0025–0029
POST /api/contentstore/v0/grading/{id}/ PATCH /api/contentstore/v3/authoring_grading/{course_key}/ ADRs 0025–0029
GET/POST /api/contentstore/v0/enrollments/ GET/POST /api/contentstore/v1/enrollments/ ADRs 0025–0029

Testing

Each new endpoint has a dedicated test module covering:

  • ADR 0026: permission boundary tests (401/403)
  • ADR 0028: routing tests
  • ADR 0029: error envelope shape tests
  • Regression test confirming old endpoint error shape is unaffected

@Faraz32123 Faraz32123 requested a review from a team as a code owner June 15, 2026 08:07
return response_data

except InvalidEnrollmentAttribute as error:
raise ValidationError(str(error)) from error
except InvalidEnrollmentAttribute as error:
raise ValidationError(str(error)) from error
except EnrollmentNotAllowed as error:
raise PermissionDenied(str(error)) from error
@Faraz32123 Faraz32123 force-pushed the feat/axim-api_improvements branch from b4f6c4c to 148eb3c Compare June 15, 2026 08:28
taimoor-ahmed-1 and others added 8 commits June 15, 2026 13:29
Standardize HomePageCoursesView
Co-authored-by: Taimoor  Ahmed <taimoor.ahmed@A006-01711.local>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat: apply ADRs to home v1 apis

* feat: apply ADR 0029 error envelope to home v3 viewset

Wires HomeViewSet (v3) into openedx/core/lib/api/exceptions's
standardized_error_exception_handler via a v3-local StandardizedErrorMixin
that overrides DRF's per-view get_exception_handler. Project-wide
EXCEPTION_HANDLER setting is intentionally left unchanged so v0/v1/v2
endpoints are unaffected.

* feat: refactor mixin so that both v3 and v4 can use it
@Faraz32123 Faraz32123 force-pushed the feat/axim-api_improvements branch from 148eb3c to 21b6e30 Compare June 15, 2026 08:29
@Faraz32123 Faraz32123 changed the title Feat/axim api improvements feat: axim api improvements Jun 15, 2026
@feanil

feanil commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

@Faraz32123, there is not a lot of context in the description or in the commit messages about WHY decisions are made. I know that for example the xblock API went from V0 to V1 but it's unclear to me what prevents us from making updates to the existing api enpoint requiring us to introduce a new one. Can you make sure the relevant commit message and the PR description have this reasoning so we can find it in the future. The ADR is the broad guide but we still need to provide the specific reasoning for given changes to make it easier for us to understand later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants