Multi-segment path parameters in Swagger 2.0—interested in a patch?

Short version

We'd like to validate an API with a dynamic, multi-segment path in it.

e.g.

#!

/root/subFolder/subFolder/subFolder

OR

#!

/root/a/b/c

Where the depth of the subfolders is unknown. In our spec, we write a path

#!

/root/{path}

Where we want {path} to match /a/b/c

Longer version

You can take a look at this ticket on Open API 3 and the associated comments: https://github.com/OAI/OpenAPI-Specification/issues/1459

If you read all the way through you'll see

What's requested there is similar to what is summarized above
There is some consideration for including the feature in OpenAPI 3.1 though there are a couple of different proposed approaches.

Problem and Solution today

While it is nice to know this might become an officially supported OpenAPI 3.1 feature in the future, we have a problem today because swagger-request-validator cannot match dynamic multi-segment paths. ApiOperationResolver assumes that the request path to be matched must have the same number of segments as the path in the specification and therefore it always reports that no paths match.

I have developed a patch and test cases which modify ApiOperationResolver as follows:

If the spec path ends in a parameter (e.g. /root/{path}), and,
the incoming request matches otherwise (so /root/a/b matches but /foo/a/b does not), and,
this is the most specific match (using the logic for 'most specific' recently introduced)

-> Then the path is a match and the operation resolves

Of course, in OpenAPI 2.0 there is no way in the specification itself to signal that we want this kind of "loose" matching. Therefore we allow the developer using ApiOperationResolver to explicitly specify which kind of matching they want in their Java code.

If this patch is accepted it will hopefully position swagger-request-validator to be able to quickly support OpenAPI 3.1 if this feature becomes part of the spec.

Please let me know if this sounds interesting. I will need to do some work to clear the patch for release so interesting in feedback first.

Comments (7)