hide the object name in the response

[Mr-Giraffe]

In our code, we defined a message as follows:

message Queue{
  string name = 1;
}
message QueueList{
  repeated Queue queues;
}

If our rpc use QueueList as the response, we will get this json:

{
  "queues": [
    {"name": "test-1"},
    {"name": "test-2"}
  ]
}

This is not a standard RESTful format. Is it possible to get the following json?

[
  {"name": "test-1"},
  {"name": "test-2"}
]

i.e., we don't want to add a layer which expose the object name defined in proto. Just the value of the object to json.

[tmc]

@Mr-Giraffe thanks for your comment.
Given the flexible nature of 'RESTful' could you supply a reason why the former should be considered 'non-standard'?

Between the fact that project uses proto3 we intend to adhere to that standard. You can't declare a direct 'repeated Message' as the response type on a grpc rpc.

Here is some api design documentation that implies having this child field for a collection endpoint: https://cloud.google.com/apis/design/standard_methods#List

This sort of divergence from grpc and proto3 would be inappropriate for this project.

[Mr-Giraffe]

@tmc thanks for your reply.
Maybe the "non-standard" is not the right word. When we design our restful api, we try to follow the format of some existing and popular style.

For example, the github restful V3 api. In their design, the list is just return an array on the top level.
This kind of design has one advantage, which makes it easier to share the object. i.e., the get api returns A, and the list api returns a list of A. A is shared. Some restful freamwork also expact this kind of response.

Current style makes sense when the response contains other thing rather than a pure list. I notice some google restful api belongs to this kind of style: https://developers.google.com/gmail/api/v1/reference/users/drafts/list

Anyway, if you guys regard this is not the scope of this project, we could find some work around.

[tmc]

Thanks for the comment. I would like if this project could accommodate that but I don't see how to do so in a way that doesn't cause a mismatch of sorts. I do think it's common that you would want to supply some metadata especially in the form of paging/cursors. Not returning objects top level ends up appropriate in many situations anyways. Thanks again for your comment! Sorry that this doesn't quite match what you wanted here.

[whisper-bye]

@Mr-Giraffe
how do you resolve this problem?

[armsnyder]

For anyone watching this issue, the solution is to use the allow_repeated_fields_in_body=true plugin option. (Supported since 1.7.0). In your proto file, set the google.api.http.response_body RPC option to the name of your repeated field.