Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs/Examples] No docs/examples for path parameter curly bracket syntax #1700

Closed
AudriusButkevicius opened this issue Sep 26, 2020 · 1 comment · Fixed by #2461
Closed

Comments

@AudriusButkevicius
Copy link

📚 Documentation

Looking at #720
it seems the path patterns support some sort of {foo=bar} templating, but I can't seem to find any docs about it, what it does, how it works, or it's use in any examples.

Furthermore, there is no indication of where users can ask questions (whether it's the issue tracker, forum, mailing list etc).

Hence I am dumping it here:

I'd like to implement a rpc method with optional parameters for paging.
Namely:

GET /books = returns all books
GET /books/{page}/{per_page} = returns paginated books

I assume I might be able to do something like:

get: "/books/{page=0}/{per_page=0}

But it seems the swagger spec generated has both parameters as required and not optional and default value is nowhere to be seen, so I assume this doesn't do what I want.

Does this really need to be two separate grpc methods?
I guess I could have additional_bindings with the path parameters, but then I get an ugly GetBooks, GetBooks2 operations.
Is there a way to control the operation name for the additional binding, so I could call it GetBooksPaginated or something?

@AudriusButkevicius AudriusButkevicius changed the title [Docs/Examples] [Docs/Examples] No docs/examples for path parameter template syntax Sep 26, 2020
@johanbrandhorst
Copy link
Collaborator

Hi Audrius, sorry for the confusion caused here. This optional syntax is for specifying a field to include a non-variable part of the, i.e:

get: "/v1/{name=messages/*}"

Means that the variable name will have the value messages/123456 when the method is invoked with the path GET /v1/messages/123456. These definitions come from http.proto, which is the spec we use for parsing the annotations.

You're absolutely right that this should be more visible and I'd love to review a PR that adds this note in a suitable place in the documentation (I think the README would be a good place to start). What do you think?

@johanbrandhorst johanbrandhorst changed the title [Docs/Examples] No docs/examples for path parameter template syntax [Docs/Examples] No docs/examples for path parameter curly bracket syntax Sep 26, 2020
johanbrandhorst pushed a commit that referenced this issue Dec 15, 2021
… multiple HTTP path/method endpoint support (#2461)

* Support standard OpenAPI paths for all valid path params for gRPC endpoints in protoc-gen-openapiv2 (#407)

* Fix issue with URL encoded path segments not being split when unescaping mode is legacy, default or all characters

* Adding docs for path template syntax and new functionality (#1700)

* Removed unused old code

* Additional tests for regular expressions

* Formatting code

* Fix lint error

* Removing duplicate test

* Adding additional test for path escaping

* Fix failing test because of path change

* Fix failing tests in code coverage

* Change determination of unescaping by supporting default mode change

* Regenerated files from changes

* Remove unused parameters in test

* Remove code warnings in test

* Implement changes from PR #2461 comments

* Correcting incorrect documentation

* Adding test case to show change in docs is warranted
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants