[FC-0118] docs: add ADR for merging similar endpoints#38262
[FC-0118] docs: add ADR for merging similar endpoints#38262Abdul-Muqadim-Arbisoft wants to merge 2 commits into
Conversation
- Propose consolidation of narrow action-scoped URLs into unified parameterised views - Document certificate generation endpoints as primary consolidation candidate - Define action/mode parameter pattern and shared service layer approach
deborahgu
left a comment
There was a problem hiding this comment.
this makes some of the PR's I saw go through last year make so much more sense. 😀
| * Existing clients calling the legacy URLs require a migration period; deprecated aliases must be | ||
| maintained until adoption drops sufficiently. |
There was a problem hiding this comment.
at least in openedx code, I'm pretty sure that these are only called internally by the instructor djangoapp, right? Although come to think of it that's probably just because this work got done last year. 😆
There was a problem hiding this comment.
You're right, within openedx the only caller is the instructor dashboard frontend, so the in-tree migration is atomic (backend + frontend together). The migration-period language was aimed at out-of-tree callers, Tutor plugins, custom MFEs, operator integrations etc
|
approved but I added a suggested change. |
- Reword "pure REST" alternative per @deborahgu's suggestion: the proposed design is already RESTful (certificate_task is the noun, POST creates the task, payload specifies the task type) - Clarify authorization model: preserve the three distinct permissions from the legacy endpoints via two-layer enforcement (coarse view-level check + per-mode service-level check). Updated implementation requirements, view docstring, and code skeleton to reflect this
|
@feanil do you need to take a look at this one? Or I can merge this PR, let me know. |
|
If @deborahgu has reviewed it, that's sufficient. Feel free to merge. |
edf7c67 to
a079a0a
Compare
Currently, Open edX APIs expose multiple narrow action-scoped endpoints for the same resource domain, duplicating permission checks, validation logic, and business logic across sibling views. This ADR proposes consolidating these fragmented endpoints into single parameterised DRF views backed by a shared service layer, using an action or mode parameter to distinguish operations
Issue: #38166