Apply FiedMask to the GET (and LIST) returns

[topherCantrell-vertiv]

🚀 Feature

The protocol-buffers documentation mentions using the FieldMask to allow the gRPC server response to specify what fields are being returned in a single GET and in a GET list operation.

Currently, the gateway only generates field-mask code for UPDATEs.

https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/field-mask

The generated code should honor a FieldMask in the response message (maybe for any verb) and use that to generate the content of the returned JSON object(s). Many REST interfaces request a subset of fields. Or a user might only have access to a limited number of fields. This FieldMask lets the gRPC server control what is shown in the return HTML.

[johanbrandhorst]

This is an application level concern, and not something that the gateway is in any place to handle. The gateway auto-generates field masks for updates because it's a well defined limited scope convenience feature for users. How would the gateway

generate the content of the returned JSON object(s)

for arbitrary methods?

[topherCantrell-vertiv]

Sorry. "Arbitrary methods" meaning all verbs that return a resource: PUT, PATCH (update), GET, but not DELETE.

Currently, the generated GO code that fills out the JSON object does this: if the value is the gRPC default value (0 for ints, False for booleans, etc) then the field is not included in the returned HTTP. We can set the option "EmitDefaults: true", and the generated GO code will add all fields to the JSON return.

By using a field-mask, we allow the grpc server to specify which fields in the response are written into the JSON. And if the field-mask is not present, then the current behavior is used: either all on or not-default depending on the setting for "EmitDefaults".

Does that make any sense? It lets the generated GO code know what values to put into the returned JSON.

[johanbrandhorst]

Thanks for clarifying the ask. I'm not convinced this is a feature that we should implement, still. Could you give more of an example where this would help? The behavior you're talking about, whether to write the zero value of the unspecified variables or not, is entirely handled by the Go protobuf stack JSON marshaler, which is external to this repository. If you want to change that behaviour, you can implement your own marshaler. As it sounds at the moment, I don't think this feature adds enough to warrant the maintenance burden or potentially confusing implicit behavior.