Swagger definitions don't handle parameters that are not explicitly required in the url

[achew22]

message Message {
  string message = 1;
}

message GetMessageRequest {
  message SubMessage {
    string subfield = 1;
  }
  string message_id = 1; // mapped to the URL
  int64 revision = 2;    // becomes a parameter
  SubMessage sub = 3;    // `sub.subfield` becomes a parameter
}

service Messaging {
  rpc GetMessage(GetMessageRequest) returns (Message) {
    option (google.api.http) = {
      get: "/v1/messages/{message_id}"
    };
  }
}

This should enable a HTTP JSON to RPC mapping as below:

HTTP	RPC
GET /v1/messages/123456?revision=2&sub.subfield=foo	GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))

Presently it does not work

[hasLeland]

I'd like to add my support for this. Right now no query parameters are added at all for the generated paths in any swagger spec. This makes most all swagger specs useless, unless you map every field in every message to path parameters, which is very dirty solution indeed.

[johanbrandhorst]

The workaround right now is to pretty much use POST for all your HTTP endpoints, as far as I can tell. I second the need for this fix.

[rgarcia]

Opened a PR that attempts to address this #199

[ambarc]

+1

[jhayotte]

+1,
@johanbrandhorst your workaround removes the possibility to have a REST API, I don't see that as a solution.
This PR #159 matches our expectation... Please merge it,

We really need something like below working

service Messaging {
  rpc GetMessage(GetMessageRequest) returns (Message) {
    option (google.api.http) = {
      get: "/v1/messages?type={type_id}&limit={limit}"
    };
  }
}

[AlekSi]

I think that issue can be closed?

[achew22]

Yep, I think this can be closed. Thanks!