New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback on operationPath
#179
Comments
Hi @RomanHotsiy, I take your point, but RFC 6901 is pretty clear as to the escaping and evaluation rules. If users really struggle in being able to specify the pointers then the first port of call should be to decorate their APIs with The proposals moving forward in future versions of OpenAPI (a.k.a. Moonwalk) will enforce If it's something you want to utilize, then I would suggest you continue to do so via an extension. |
What about making the It has a side-benefit of not needing to explain mutual exclusivity in the spec. |
My concern with transferring As it stands, |
Hey folks 馃檶 !
I've noticed you added support for
operationPath
for ability to target operations without operationId using JSON Pointer.I have some feedback based on our experience working with this kind of format (JSON Pointer).
We have our users constantly confused about the correct format for the pointer:
#/paths/pet/findByStatus/get
#/paths/pet~1findByStatus/get
What we ended up using is to use separate values for path and HTTP verbs. In our WIP implementation we added support for:
I think this approach should work for the future versions of OpenAPI too.
What do you think about it? I can open PR with adjustments if you like it!
The text was updated successfully, but these errors were encountered: