Skip to content

docs: ADRs for axim api improvements#38738

Open
Faraz32123 wants to merge 21 commits into
masterfrom
docs/ADRs-axim_api_improvements
Open

docs: ADRs for axim api improvements#38738
Faraz32123 wants to merge 21 commits into
masterfrom
docs/ADRs-axim_api_improvements

Conversation

@Faraz32123

Copy link
Copy Markdown
Contributor

No description provided.

Faraz32123 and others added 18 commits June 10, 2026 15:51
…ble change (#38188)

Co-authored-by: Muhammad Faraz  Maqsood <faraz.maqsood@A006-01130.local>
Currently, authorization logic is implemented inconsistently across views, serializers, and custom access checks. This ADR will define a consistent approach using DRF permission classes, object-level permissions, and queryset scoping where appropriate.

Co-authored-by: Taimoor  Ahmed <taimoor.ahmed@A006-01711.local>
Add edx-platform/docs/decisions/0030-ensure-get-requests-are-idempotent.rst as an accepted ADR.
Define policy that GET endpoints must be strictly read-only, with side effects moved to explicit write endpoints or async event pipelines.
Include edx-platform relevance, anti-pattern vs preferred code examples, and rollout guidance for testing and migration.
- Propose adoption of drf-spectacular across Open edX services
- Require @extend_schema decorators for all API endpoints
- Document request/response schemas, status codes, and error conditions
- Add context explaining what api-doc-tools is and its relationship
  to drf-yasg
- Document deprecation and archival of api-doc-tools as a consequence
- Add migration guide mapping api-doc-tools decorators and URL helpers
  to their drf-spectacular equivalents
- Add rejected alternative for updating api-doc-tools internals
- Add rollout step for final archival cutover

Closes review comment by @feanil
…ompatibility analysis

Address review feedback on FC-0118 ADR 0027:

- Add context paragraph explaining what api-doc-tools is (drf-yasg shim,
  decorators it provides, schema view, OpenAPI 2.0 output)
- Document deprecation of api-doc-tools and drf-yasg as a consequence,
  including transition-window behavior
- Add detailed 8-point incompatibility analysis explaining why drf-yasg
  cannot be replaced with drf-spectacular inside api-doc-tools (recorded
  in the ADR itself for future reference)
- Add migration plan for existing api-doc-tools consumers with concrete
  decorator/import/setting mapping
- Update Rollout Plan to track api-doc-tools removal
- Add references to drf-spectacular migration guide, drf-yasg upstream
  status, and api-doc-tools repository
@Faraz32123 Faraz32123 force-pushed the docs/ADRs-axim_api_improvements branch from adf2e7b to ad4b7ba Compare June 10, 2026 10:51

@feanil feanil left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One note but generally looks good.


**Example serializer and APIView using DRF best practices:**

.. code-block:: python

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we've mentioned input and output serializers, I think it would be worth it for the example to show how to have both and how they can be different.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@feanil I have added a commit, let me know if the example looks good now. I'll change it accordingly.

Abdul-Muqadim-Arbisoft and others added 2 commits June 19, 2026 12:37
…Is (#38309)

* docs: ADR for documenting and consolidating internal MFE APIs
Define a plan to document all undocumented internal LMS APIs consumed
by MFEs into stable, OpenAPI-described contracts. Introduces a
consolidated config endpoint pattern with optional course/user context,
authentication boundaries, and a rollout plan following OEP-21 DEPR
process.

* docs: add ADR for canonical MFE configuration endpoint

Record that /api/frontend_site_config/v1/ is the canonical endpoint for
MFE/front-end runtime configuration (frontend-base SiteConfig, OEP-65) and
that /api/mfe_config/v1 is legacy, on the DEPR path tracked in #37255 and
added, and that user-context data (roles, permissions) belongs on
resource-oriented endpoints rather than on a configuration payload.
Documentation/schema coverage is deferred to the API Documentation &
Schema Coverage ADR (#38189).

Partially supersedes ADR 0001 (MFE Config API).

Part of FC-0118 Open edX REST API standardization (#38137).
Refs #38280
* docs: add ADR for standardizing authentication patterns

* docs: resolve confusion & update the ADR based on OEP-0042

* docs: support multiple valid auth schemes & deprecate BearerAuthentication

* docs: change wording for decisions a bit.

* docs: add real examples in accordance with our updated decisions

* docs: sync ADR with edx-drf-extensions issue 284

openedx/edx-drf-extensions#284

* docs: make doc more explicit & address comments

* docs: move Bearer auth depr plan out of ADR

Move BearerAuthentication depr plan out of this doc So that it resides in single place i.e. to its deprecation ticket.

* docs: add a pointer file in oauth_dispatch for this ADR

* docs: make decision more clear

* docs: make authentication_classes usage more clearer

* docs: adress the comment related to session authentication
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.

6 participants