Is an OpenAPI path with multiple variables in the same segment valid?

Question

Is the following valid?

GET image/{id}/{palette}.{file_extension}

I want to be able to do something like this: example:

GET image/1/falsecolor.jpg
GET image/4/alternative.png
GET image/9/falsecolor.tiff

Basically, the palette defines how is the image is colored (color palette) and the extension is the file format better suited for your application (mobile deals best with one file format, web with another, etc), all OpenAPI linters I tried do validate it, there is nothing that I can find in the documentation for the OpenAPI that says that this is not a valid approach, but when I uploaded this to Postman, it borked beyond recognition, loading the palette and the file extension both as collection variables instead of API properties, and Postman is supposedly OpenAPI compliant/compatible, so I am wondering if this is actually a non-compliant path parameter.

Answer 1

Yes, partial path parameters are valid in OpenAPI.

However, they can result in ambiguous parsing if the parameter value contains the separator character. For example, given the path template /{palette}.{file_extension} and the request URL /false.color.jpg, what values should the server assume?

• palette="false"
file_extension="color.jpg"
• palette="false.color"
file_extension="jpg"

Some tools (notably AWS API Gateway) choose not to support partial path parameters and require that path parameters occupy the entire path segment (that is, /{foo}/{bar} but not /{foo}.json or /{foo}-{bar}).

Answer 2

Postman has sent an answer confirming the behavior, it is a current limitation in their implementation.

There are limitations to our current collection format, which does not allow more than one path variable within a path segment for example - /files/{file-id}.{format} and also parts of the path segment can't be delimited as a path variable for example - /file.{format}. In order to overcome this current limitation, we use collection variables to represent this path variable. This will not break any behavior but at the same time, information loss from OpenAPI is expected. Having said that users can rely on schema documentation which doesn't have these limitations and preserve the path parameters as configured by the users.

They also said this is something they want to change in the future, just no ETA on that for the moment.

I'd like to thank everyone that put their time to answer this question, it helped alot.