Ordering of matches when no path is concrete
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 文档
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- openapi
- 领域
- api, documentation
调研方向
从链接的 OpenAPI 3.0.3「Patterned Fields」部分以及 OpenAPI Specification issue #1459 中的讨论开始。将其中的指导与本 issue 中的 templated path 示例进行比较，并确定是否存在规范性的排序规则。完成的标准是：通过一条有文档记录的规则，或明确说明该规范未定义此类规则，解决这一歧义。
由索引模型根据 Issue 内容生成。
描述
I'm a contributor for an OpenAPI Validator project, and one of our users has raised an issue that their the spec is not matching in the order they would expect (you can see the issue here).
The issue effectively boils down to the user expecting a path with just one templated segment to be matched over a path with more than one templated segment, i.e.:
/{id1}/{id2}/{id3}
/resource/{id}/new <- Expect this one to be picked
With a request path like: /resource/1/new.
Currently we are matching simply based on the order of the paths as defined by the user in their specification file (which is probably not the correct approach). My question is whether it is specified anywhere how to resolve/match multiple templated matches?
Looking at the relevant part of the OpenAPI3 spec, while it discusses preferring a concrete path over a path which uses templates, from the spec I couldn't see how paths would be chosen if both match the request, and both use templates in the path. Since the examples in the spec are fairly short, I wasn't sure if the above example would fall into the ambiguous category or not.
I did manage to find a discussion in your issues here which hints at the fact most people would match a path with more concrete segments, over one with less. Since we are a validation tool, I would prefer to be able to apply concrete rules.
Do you have any advice/further reading on matching paths like the above example?
- 主要语言
- Markdown
- 星标
- 31.2k
- 派生
- 9.2k
- 平均合并
- 2 天 9 小时
- 30 天内合并 PR
- 17
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
OAI/OpenAPI-Specification 的其他 Issue
-
Housekeeping
难度 1/5 1 小时以内 新手友好度 45/100
OAI/OpenAPI-Specification#5566 ·
维护者通常 1 天内回复
-
Housekeeping
难度 1/5 1 小时以内 新手友好度 35/100
OAI/OpenAPI-Specification#5562 · 4 条评论 ·
维护者通常 1 天内回复
-
Housekeeping
难度 5/5 一周以上 新手友好度 10/100
OAI/OpenAPI-Specification#5556 · 3 条评论 ·
维护者通常 1 天内回复
-
v3.2.1 release可能重新可做 @lornajane 于 31 天前认领，目前没有进行中的 PR。 未关闭
OAI/OpenAPI-Specification#5460 · 11 条评论 · 1 个 reaction · 已指派 1 人 ·
维护者通常 1 天内回复
-
param serialization
难度 5/5 一周以上 新手友好度 25/100
OAI/OpenAPI-Specification#5366 · 12 条评论 ·
维护者通常 1 天内回复
查看 OAI/OpenAPI-Specification 的全部 Issue
相似的 Issue
-
comp/gateway comp/plugins duplicate P3 type/bug
难度 2/5 1-3 小时 新手友好度 82/100
NousResearch/hermes-agent#137019 ·
维护者通常 1 天内回复
-
status: team-only type: dependency-upgrade
难度 2/5 1-3 小时 新手友好度 65/100
spring-projects/spring-boot#52138 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
anthropics/sandbox-runtime#696 ·
维护者通常 2 天内回复
-
confluence: a paged listing's links re-encode a parameter they carry, where real carries it as sent未关闭fidelity
难度 2/5 1-3 小时 新手友好度 63/100
维护者通常 1 天内回复
-
area:deploy task
难度 2/5 1-3 小时 新手友好度 72/100
wilanis/wilanis-js#1017 ·
维护者通常 1 天内回复