Repository navigation
docs(faq): name Azure API Management in the OpenAPI version guidance - #865
Merged
Merged
Conversation
The 3.0 versus 3.1 entry named no downstream consumer. Add Azure API Management, which supports OpenAPI 2.0 and 3.0.x and accepts 3.1 for import only, and link to Microsoft import restrictions instead of restating them. Refs #861 Co-authored-by: sisyphus-dev-ai <sisyphus-dev-ai@users.noreply.github.com>
The places where readers choose a version, the --openapi-version option and the OpenAPI version selection section, did not point to the FAQ entry that explains the choice. Refs #861 Co-authored-by: sisyphus-dev-ai <sisyphus-dev-ai@users.noreply.github.com>
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are reported for the documentation changes clarifying Azure API Management compatibility and linking version-selection guidance.
No open issues 🎉
What changed in this PR
Clarifies OpenAPI version selection for Azure API Management users and makes the guidance easier to find from the CLI and configuration documentation. This is documentation-only and is intended to merge after #863’s OpenAPI 3.0 compatibility fix.
Changes:
- Names Azure API Management’s supported versions and import-only support for 3.1, with a link to Microsoft’s restrictions.
- Links both version-selection entry points to the existing FAQ.
| File | Description |
|---|---|
docs/faq.md |
Adds Azure API Management compatibility guidance and Microsoft’s reference link. |
docs/configuration.md |
Links version selection to the FAQ. |
docs/cli.md |
Adds a guidance link to the --openapi-version option. |
Review effort: Balanced
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
The FAQ entry on choosing OpenAPI 3.0, 3.1 or 3.2 named no downstream consumer, and the places where readers choose a version did not point to it. This names Azure API Management and links the entry from the CLI and configuration docs.
Changes
docs/faq.md: the existing entry now says that Azure API Management supports OpenAPI 2.0 and 3.0.x and accepts 3.1 for import only, and links to Microsoft's import restrictions instead of restating them.docs/cli.mdanddocs/configuration.md: the--openapi-versionoption and the "OpenAPI version selection" section link to that entry.Validation
Run locally:
mkdocs build --strict: exit 0 with no new warnings. The FAQ anchor used by both links exists in the built page.GitHub CI on
aaef342: all check runs completed with no failures, including the requiredAnalyze,bandit,ci-required,PR titleandsemgrepcontexts.Related Issues
Closes #861
Merge after #863. The guidance recommends OpenAPI 3.0 for API Management, which for routes that use
@validate_httpdepends on the fix in that PR. For that reason the known-limitation note listed in #861 is intentionally not added.