Add footer links to the API documentation - #80
Conversation
dennisvang
left a comment
dennisvang
left a comment
There was a problem hiding this comment.
Hi @mihailefter this looks good overall, but I think it may be worth reconsidering the variable naming for clarity.
In essence we are trying to advertise two types of API documentation:
- human readable (HTML)
- machine readable (JSON)
Perhaps this could be reflected in a consistent way in the variable names and in the footer link labels?
Also perhaps check for <!doctype html> to identify a human readable document?
To identify the machine readable openapi doc, maybe isOpenApiDoc could check for the required openapi field in addition to the paths field. Note from the spec:
In addition to the required fields, at least one of the
components,paths, orwebhooksfields MUST be present.
Co-authored-by: Dennis <29799340+dennisvang@users.noreply.github.com>
|
Hi @dennisvang! Thanks for the review. I've updated the variable names and footer labels to distinguish HTML and JSON consistently. |
dennisvang
left a comment
dennisvang
left a comment
There was a problem hiding this comment.
Looks great @mihailefter
Well done, very thorough. 🙂
Thanks!
|
Hi @mihailefter I'm closing the branch to keep things clean. |
2 participants
Add links to the FDP's API documentation in the footer, both Swagger UI and OpenAPI, visible on every page.
The client already discovers these via
dcat:endpointDescription, and now reuses that discovery to expose the links. When no OpenAPI document can be resolved, a short warning is shown instead, matching the gap discussed in #64.The "more prominent link only on the root page" suggestion was not implemented because the root page's own Endpoint description row already renders both URLs as working links, so adding another link there seemed redundant.
Fixes #42