fix: honest HATEOAS links for POST search + backup envelope alignment #18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/hateos-search-links"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fix: honest HATEOAS links for POST search + backup envelope alignment
1. Search pagination links (fixed)
POST /api/doujins/searchreturned GET-style pagination links that were unfollowable — the endpoint only accepts POST, and the filters live in the request body. Now generates honest POST links: self/next/prev all point to/api/doujins/searchwithmethod: POST. Also adds aresetaction pointing toGET /api/doujins.2. Backup envelope alignment (fixed)
The backup endpoints returned bare arrays/objects instead of the standard
{data, links, actions}envelope used everywhere else. Now aligned:GET /api/backups→CollectionResponse<BackupDto>with links/actionsPOST /api/backups→ResourceResponse<BackupDto>with self/delete linksDELETE /api/backups/{fileName}→ unchanged (204 No Content)Added
BuildBackupLinksandBuildBackupActionsto HypermediaHelpers. Removed the redundantCreateBackupResponseDTO (identical fields toBackupDto).Full endpoint sanity check
All 7 endpoint files reviewed:
Summary
Summary
Coverage
DoujinManager.ApplicationCore - 84.8%
DoujinManager.Infrastructure - 91.6%
pshot
DoujinManager.RestAdapter - 84.2%
E5CB12CEAC5BBBEA65844E1C05F9ADA4DA38B848075C41304FC6A1ABF77__ValidationAttr
ibuteCache
DoujinManager.Server - 16.7%
🤖 Hermes automated review: no blocking issues found
Reviewed the single changed file
backend/src/DoujinManager.RestAdapter/Endpoints/SearchEndpoints.cs(+23/−2) on head55d718c6. The fix is correct and the reasoning in the PR body is sound: GET-style links on a POST-only endpoint were genuinely unfollowable (405).Static security scan: clean (C# only; no secrets, shell injection, eval/exec, or SQL injection in added lines).
Verification of the change
Envelopes/ResponseEnvelope.cs:Link(Href, Method = "GET", Type?)→new("/api/doujins/search", "POST")✓HypermediaAction(Name, Title?, Method, Href, Type?, EncodingType?)→ bothsearchandresetactions match positionally ✓HypermediaHelpers.BuildCollectionLinks:nextwhenPage < TotalPages,prevwhenPage > 1,selfalways present ✓next/prevlinks intentionally drop the page number from the URL. The current page is available in the response'sPage.PageNumber, so a client can computecurrentPage + 1. The PR body documents this contract clearly. ✓resetaction (GET /api/doujins) is a sensible affordance for returning to the unfiltered list.Minor note (non-blocking)
SearchIntegrationTests.cs→Search_Pagination_Exposes_Navigation_Links(line ~330) asserts thatself/nextkeys exist, but does not assert thatmethod == "POST"or thathref == "/api/doujins/search". This means a future regression that reverts the links to GET style would not be caught by the test. Consider strengthening the assertion, e.g.:Not blocking —
SearchEndpointsshows 100% line coverage in CI, and the link-shape correctness is the contract this PR fixes.Verification
55d718c6— forgejo-actions coverage comment #308 is current (generated 06/29 14:47:08 UTC, after the head commit; line 83.6%, branch 49.4%). ci.yml posts coverage only on successful build+test, so build+test passed. Local build/test skipped per CI-evidence policy.Note: this is not a formal Forgejo review approval — the current MCP integration can post conversation comments but cannot create inline review comments or approval states.
Automated daily review. I never merge PRs.
fix: honest HATEOAS links for POST search endpointto fix: honest HATEOAS links for POST search + backup envelope alignment