-
Notifications
You must be signed in to change notification settings - Fork 9.2k
Open
Labels
clarificationrequests to clarify, but not change, part of the specrequests to clarify, but not change, part of the specrequest matchingMatching requests to URL templates, media types, etc.Matching requests to URL templates, media types, etc.
Description
Currently the support for path segments is ambiguous even in simple cases:
Consider:
paths:
/{foo}:{bar}/update:
post:
summary: Example API with multiple parameters
parameters:
- name: foo
in: path
description: Foo
required: true
schema:
type: string
- name: bar
in: path
description: Bar
required: true
schema:
type: string
If the URL /a:b:c/update
is received, there are two possible parses which, as far as I can tell, the spec doesn't state which is correct.
foo
=a
,bar
=b:c
foo
=a:b
,bar
=c
This means that two different implementations may have different interpretations of how parameters map through.
Note, from an implementation perspective, this gets more challenging, as in order to parse the URL to work out which operation it is, you need to know the full structure of the path parameter, as that may break the ambiguity (e.g. if bar
is an enum
which can only take values c
, or d
, then the parse collapses into the second option).
jchook
Metadata
Metadata
Assignees
Labels
clarificationrequests to clarify, but not change, part of the specrequests to clarify, but not change, part of the specrequest matchingMatching requests to URL templates, media types, etc.Matching requests to URL templates, media types, etc.