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

Allow final url path parameter to be optional #1005

Closed
veqryn opened this issue Aug 26, 2019 · 2 comments
Closed

Allow final url path parameter to be optional #1005

veqryn opened this issue Aug 26, 2019 · 2 comments

Comments

@veqryn
Copy link

veqryn commented Aug 26, 2019

I might be doing something wrong, but I was sort of expecting to be able to have the last url path parameter be optional.

Example:
If you have the rest endpoint /customers, it will return information on all customers.
And if you have the rest endpoint /customers/123, it will return information on customer id 123

syntax = "proto3";

package stuff;

import "google/api/annotations.proto";

service MyAPI {
	rpc CustomersGet(CustomersGetReq) returns (CustomersGetResp) {
		option (google.api.http) = {
			get: "/customers/{id}"
		};
	}
}

message CustomersGetReq {
	uint64 id = 1;
}

message CustomersGetResp {
	repeated CustomerDetail customers = 1;
}

message CustomerDetail {
	uint64 id = 1;
	string name = 2;
	// etc with more info
}

Any attempt to curl just /customers returns a 404, with that endpoint not existing.

In the end, this worked:

	rpc CustomersGet(CustomersGetReq) returns (CustomersGetResp) {
		option (google.api.http) = {
			get: "/customers"
			additional_bindings {
			  get: "/customers/{id}"
			}
		};
	}

But the downside is that the above produces two swagger endpoint definitions, and also allows things like this, which should not be allowed: /customers?id=123

So, is there a way to do this, without creating a second rpc definition with a new name and new request parameter?

@johanbrandhorst
Copy link
Collaborator

This is not something I'm sure we should support. What you're describing sounds to me like two different RPCs, CustomersGet and CustomersList (using your terminology). Why not have two endpoints? Presumably the response types will be different?

@johanbrandhorst
Copy link
Collaborator

I will close this, please let me know if you're still interested in this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants