Open bvwells opened 4 years ago
Hi Ben!
Thanks for the bug report. That's really unfortunate, good find. Could you link to the specific part of the swagger definition in our examples that is wrong, and what should it look like? Would you be able to help us get this fixed? I'd be happy to assist where I can. I would start looking in https://github.com/grpc-ecosystem/grpc-gateway/blob/master/protoc-gen-swagger/genswagger/template.go.
I believe that the issue in a_bit_of_everything.proto is caused by the following annotations:
rpc Lookup(sub2.IdMessage) returns (ABitOfEverything) {
option (google.api.http) = {
get: "/v1/example/a_bit_of_everything/{uuid}"
};
}
rpc DeepPathEcho(ABitOfEverything) returns (ABitOfEverything) {
option (google.api.http) = {
post: "/v1/example/a_bit_of_everything/{single_nested.name}"
body: "*"
};
}
The swagger specification generated has the following paths:
GET: /v1/example/a_bit_of_everything/{uuid}
POST: /v1/example/a_bit_of_everything/{single_nested.name}
I'll have a dig and see what I can find...
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Reopening
@jackwootton are you interested in fixing this?
I can take a look, but noticed the file you recommended starting with (above), cannot be found https://github.com/grpc-ecosystem/grpc-gateway/blob/master/protoc-gen-swagger/genswagger/template.go
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is important to me for a different reason. When creating services based on Google's API recommendations (or even Google's APIs themselves), it is typical for a resource to be identified by a canonical name
, which is a URN, rather than being split up into segments.
However, it is possible to deterministically translate using the (google.api.resource).pattern
bindings to build out a more tightly-constrained path. runtime
does this.
This would be a backwards-incompatible change to the generated swagger docs, so I imagine it would need to be configurable and default to the current behavior.
I'll be working on it in my own fork because it's a feature that I need; would you be willing to accept a pull request for that change?
I'd be happy to review any PR of course but we're unlikely to merge a breaking change
🐛 Bug Report
Invalid swagger specifications are generated when trying to have get/patch requests on same path. The issue arises through the recommended use of field masks for the updating of a resource. This seems like a bit of a UX issue as the workaround is to not use field masks for update rpcs.
Apologies if there is a mistake in how I've added annotations to the protocol buffer service definition.
To Reproduce
Take the following protocol buffer definition:
Run the protoc-gen-swagger generator:
Expected behavior
I would expect a valid swagger specification to be generated or an error in the generation process.
Actual Behavior
The swagger specification is generated successfully, but is invalid. Validating the swagger specification shows, e.g. in swagger editor (https://editor.swagger.io/)
A similar issue can also be seen in https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/a_bit_of_everything.swagger.json which is an invalid swagger specification.
Let me know if you require any further information.