Values containing slashes in URL template?

[dmitshur]

From reading https://github.com/google/googleapis/blob/master/google/api/http.proto, it suggests that some parameters may be a part of the URL template, for example:

get: "/v1/messages/{message_id}"
get: "/v1/users/{user_id}/messages/{message_id}"

HTTP	RPC
GET /v1/messages/123456	GetMessage(message_id: "123456")
GET /v1/users/me/messages/123456	GetMessage(user_id: "me" message_id: "123456")

However, if I'm reading this spec right, those values may not contain slashes, can they?

For example, suppose I wanted to define:

get: "/v1/dirs/{dir_path}"

And have the following HTTP requests match:

HTTP	RPC
GET /v1/dirs/foo	GetDirs(dir_path: "foo")
GET /v1/dirs/foo/bar	GetDirs(dir_path: "foo/bar")
GET /v1/dirs/foo/bar/baz	GetDirs(dir_path: "foo/bar/baz")

Only the first will get matched, the other two will not. Is that so?

Is it true that there's no way to have all 3 of the above paths get matched, as long as grpc-gateway follows that google.api.http spec? Is the only alternative to use URL queries, like
GET /v1/dirs?dir_path=foo/bar/baz?

If so, that seems to put a heavy restriction on one's ability to create RESTful APIs using grpc-gateway, since it's often desirable to have some slash separated paths as values.

[dmitshur]

I just realized (thanks @sqs) that I missed a very important bit:

* matches a single path component, ** zero or more path components.

So it is possible.

[dmitshur]

Confirmed that it works. It's possible to achieve the above by doing:

get: "/v1/dirs/{dir_path=**}"

[slimsag]

@shurcooL Do I understand your findings here correctly?

get: "/v1/dirs/{dir_path}"

Would match only a single path element (but it could be a URI encoded path). Whereas:

get: "/v1/dirs/{dir_path=**}"

Would match multiple path elements (that are not URI encoded)?

[dmitshur]

@slimsag Yes, the above is correct.

(but it could be a URI encoded path)

I don't think so. This is a url path element, not a query parameter. Edit: I could be mistaken, see e.g., golang/go#5777 (comment).

---

However, I'm reopening this because I find that it only works if such segment is at the end of the route. It doesn't seem to work when it's in the middle.

For example, this works:

get: "/v1/dirs/{dir_path=**}"

// They all work.
/v1/dirs/foo
/v1/dirs/foo/bar
/v1/dirs/foo/bar/baz

But this does not work:

get: "/v1/dirs/{dir_path=**}/.files"

// None of these get matched.
/v1/dirs/foo/.files
/v1/dirs/foo/bar/.files
/v1/dirs/foo/bar/baz/.files

Is that a bug?

[yugui]

@shurcooL Your question is whether the multi-segment wildcard ** is greedy or not.
I believe it is and I implemented the match mechanism as greedy by intention. But it is not clearly described in the spec.
We might need to ask the spec owner.

[dmitshur]

Your question is whether the multi-segment wildcard ** is greedy or not.

That is true. I agree that the spec doesn't seem to specify one way or the other. Thanks for looking into it.

[dmitshur]

Thank you for resolving this!