-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
protoc-gen-swagger doesn't generate any request objects for GET/DELETE #747
Comments
Thanks for your issue report. Could you include an example protofile that reproduces the issue? |
Sure thing: syntax = "proto3";
package test;
import "google/protobuf/empty.proto";
import "google/protobuf/timestamp.proto";
import "google/api/annotations.proto";
import "protoc-gen-swagger/options/annotations.proto";
option go_package = "gitlab.myteksi.net/gophers/go/ads/admanager/pb";
option (grpc.gateway.protoc_gen_swagger.options.openapiv2_swagger) = {
base_path: "/test";
info: {
title: "Test";
version: "1.0";
};
};
service Admanager {
rpc GetCooldude(GetCooldudeRequest) returns (GetCooldudeResponse) {
option (google.api.http) = {
get: "/Cooldudes/{CooldudeID}"
};
}
}
message Cooldude {
uint32 CooldudeID = 1;
string Name = 2;
bool Deleted = 3;
bool Active = 4;
uint32 ExternalCooldudeID = 16;
}
message GetCooldudeRequest {
uint32 CooldudeID = 1;
}
message GetCooldudeResponse {
Cooldude Cooldude = 1;
} |
Is it possible the request object isn't in the file as you expected because its a path parameter? What does the generated swagger file look like? What did you expect it to look like? |
I'm not sure I understand. The request object contains a path parameter, but it's not "a path parameter." As for the generated swagger file, I see everything I expect except no GetCooldudeRequest. This is missing:
|
It doesn't create a type definition unless it needs to. This get request has only one parameter, and it's populated in the path (i.e. by calling |
I don't think I understand? The response objects are all generated correctly. The requests are all missing. You're saying that's not a bug? This happens when there are query parameters, it happens when there are path parameters. Anything without a body will not have it's request object show up in swagger. |
Yes, that is indeed intentional. Why would they? |
It's when there is no need to provide any JSON input that it doesn't get generated. |
Doesn't that leave query parameters undocumented? In my case, the swagger is being used to generate a client for the API and unless these requests are documented, it has no idea how to construct requests. |
No, the path and query parameters are defined in the method definition, as per the OpenAPI v2 standard. Your swagger generator should have no problems generating appropriate request objects. |
OK i'm going to circle back with the folks who wrote the generator. Thanks for your help! |
Which generator is this, out of curiosity? I've used different generators with the generated swagger files without problems. Make sure it's a v2 generator though. |
For anyone who is missing all the Request type in the generated json file, you can add ex:
|
Bug reports:
Fill in the following sections with explanations of what's gone wrong.
Steps you follow to reproduce the error:
What did you expect to happen instead:
I noticed #505 which seemed similar. I tried commenting removing the if statement below this comment:
(Line: 171) // Request may be fully included in query
and that seemed to help. I have no idea if that has any side effects, I never really dug into the code. This gets me unblocked, but I did want to file a report in case anyone else is having this issue.
What's your theory on why it isn't working:
I really couldn't say. I didn't read all the code.
The text was updated successfully, but these errors were encountered: