Recognize path parameters in path segment fragments #39

[elakito]

PR for #39

[casualjim]

I am not sure if this is supported for openapi 2.0 spec

[codecov]

Codecov Report

Merging #40 into master will increase coverage by 0.04%.
The diff coverage is 90%.

@@            Coverage Diff             @@
##           master      #40      +/-   ##
==========================================
+ Coverage   84.49%   84.53%   +0.04%     
==========================================
  Files          10       10              
  Lines        1412     1429      +17     
==========================================
+ Hits         1193     1208      +15     
- Misses        177      178       +1     
- Partials       42       43       +1

Impacted Files	Coverage Δ
spec.go	85.89% <90%> (+0.08%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a52193a...6de7a6b. Read the comment docs.

[elakito]

Hi @casualjim, thank you for looking into this. I don't find the Open-API 2.0 spec explicitly allowing this URI template usage but neither forbidding this usage of URI templates. There is a related ticket about this URI template usage at OAP/OpenAPI-Specification where Ron mentioned that the spec itself does not forbid this usage.
OAI/OpenAPI-Specification#1248
regards, aki

[casualjim]

ok, but making this work for just validation might not be enough, are you planning on also sending a PR to the runtime to support this in the router?

[elakito]

Yes. i'll work on the corresponding change to the server side and create a PR. It seems the denco code that does the parameters extraction needs to be modified. The path matching is actually working and the operation is fired but the parameters are not extracted correctly. By the way, why the denco code is in middleware/ and not in vendor? Has it been customized locally?
thanks.

[elakito]

Hi @casualjim,
Initially, I thought we had to modify the denco code so that the parameters are matched and extracted from that layer. But upon looking in it more, it would be better to not change the denco code but pass a different url template from go-openapi (i.e., just one param per segment) to let it match and extract the entire segment from the denco layer, and do the actual parameter matching using this extracted string against the real parameters. There is a limitation in this approach (i.e., there is no backtracking once matched but if that is required, the denco code will need to be modified in an incompatible way, which we can avoid for now).

By the way, without this change in go-openapi/runtime, the client side code already works fine and also the server side code if there is one parameter per segment e.g.
/foo/lis{fragment}

So maybe, you could merge this PR into validation and I can open an issue in runtime to track this more-than one param per segment at the server side issue?

regards, aki

[casualjim]

@elakito 🥇 thanks