Not possible to extract request parameters?

1

I’m trying to expose a user search endpoint and initially tried this:

/user?searchWord={searchWord}

but I get:

KLX-00613 HTTP API path template for [com.hiive.user.control.UserControllerService.SearchUser] could not be parsed
[info] Expected ‘/’, ‘:’, path literal character, or end of input at character 24:
[info] /user?usernameFragment={usernameFragment}

So I guess I’ll have to do something like:

/user_search/{searchWord}

But more generally is there a way to inspect the request parameters in a controller action?

thanks,

-m

2

Hi @maristi,

This should work fine, just remove query params from the url mapping, since query params are just request params, check for instance this sample:

@GetMapping("/user")
  public Effect<String> get(@RequestParam String searchWord) {
    return effects().reply("asd" + searchWord);
  }
3

Note that in case you’re using one of our protocol-first SDKs the solution is similar. Just remove the params from the url mapping on your proto definition. Any query param that matches a field in the incoming request type should be mapped automatically.

4

A complete reference for HTTP mapping can be found here:

Any parameters in the input message that are not mentioned in the path are automatically extracted from query parameters. They don’t need to be explicitly defined in the path template (this is after all, a template for just the path, not the query string). So, your solution is to do this:

message UserRequest {
  string username_fragment = 1;
}

service Users {
  rpc SearchUser(UserRequest) returns (User) {
    option (google.api.http) = {
        get: "/user"
    };
  };
}
5

Wonderful! thank you guys and especially @jroper for sharing docs to the internal gRCP transcoding for all the gory details. -m

6

I should point out, I’m not sure if we’ve implemented 100% of the spec, there may be some corners of the spec that haven’t been implemented, and may even be some small parts we’ve got wrong. Our implementation has been used for over 3 years now, so it’s fairly robust, but if you find any issues, please raise them here or with support.

1 Like