Repository navigation
docs(architecture): list the verbs the named paths actually serve - #422
Merged
Merged
Conversation
The §6 roster names a path but listed fewer methods than that path serves, so a reader taking the verb list as complete could not rename an API key, could not see where a sharing is edited, and would not know an admin can assign a user to a department. The sibling departments line already spells out its :id sub-path with its verbs; these three now follow the same shape. Verified against router() in src/routes/mod.rs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three lines in the API roster (
docs/architecture.md§6) name a path but list fewer methods than that path serves, so a reader who takes the verb list as complete cannot tell that the operation exists.POST/GET/DELETE /api/api-keysPOST/GET /api/api-keys+PATCH/DELETE /api/api-keys/:idPOST/GET/PATCH /api/sharingsPOST/GET /api/sharings+PATCH /api/sharings/:idGET /api/admin/usersGET /api/admin/users+PATCH /api/admin/users/:id(department only)What each omission cost a reader:
PATCH /api/api-keys/:idis how a key gets renamed (dao::rename_api_key); the roster only showed create / list / revoke. The same line also putDELETEon/api/api-keyswhen the revoke route is/api/api-keys/:id.PATCHon/api/sharings, while the edit route is/api/sharings/:id— the line named the verb but not where it lives.PATCH /api/admin/users/:idis the only write to a user an admin has (UserPatchcarriesdept_idand nothing else). Without it the roster makes the admin's user list read as read-only.The section says it groups by functional face rather than listing every route, and that stays true — this change adds no new face, it completes three that were already named. The sibling
departmentsline immediately below already spells out its:idsub-path with its verbs (GET/POST /api/admin/departments+PATCH/DELETE /api/admin/departments/:id), so the shape used here is the one the table itself already established.The stated authority for this table is
router()insrc/routes/mod.rs; every verb above was checked against it, and each handler's own doc comment names the same path (/// PATCH /api/api-keys/:id,/// DELETE /api/api-keys/:id, andsharing::patch/admin::patch_userboth takingPath(id)).Related Issue
None — the repository's issue list is empty; this is a documentation correction found by comparing §6 against
router().Changes
docs/architecture.md, 3 lines changed. No code, no config, no data-structure change.Tests
cargo test— 579 passed, 0 failed.cargo fmt --check— passes.docs/architecture.md(src/deploy_gate.rsstates it does not cover the file, and no other gate reads this table).Checklist
docs/).