在grpc服务调用中使用包装器请求比普通消息有明显的好处吗？

Question

假设我们有一条消息，其中包含数据库中某些记录的ID

message Record {
    uint64 id = 1;
}

我们还有一个rpc调用，它返回表DATA中表示记录的所有行。

rpc GetDataForRecord(Record) returns (Data) {}

例如，如果我们将记录包装在

中

RqData{
    Record id = 1;
}

然后，一旦我们需要返回，例如，＆＃34;活跃＆＃34;数据，我们不需要制作

GetActiveDataForRecord

相反，我们可以将RqData扩展为：

RqData{
    Record id = 1;
    bool use_active = 2;
}

并使用

rpc GetDataForRecord(RqData) returns (Data) {}

知道这个新功能的客户端将能够调用它，而较旧的客户端将只使用它，因为它只传递Rq包装器中的Record部分，而不指定是否有效。

以下是问题：是否真的有理由将所有内容包装成一个单独的请求，或者我是否过度思考并只是通过简单的结构？< / p>

我想要考虑未来，但不确定我是否过度复杂化。

Answer 1

一般而言，制定针对特定方法的请求和响应是一件好事，并受到鼓励。对于Foo方法，您有FooRequest和FooResponse。拥有该方法的专门消息允许您添加新的“参数”，如您所述。

但是对于某些情况来说，打破这种模式并避免包装是很好的;这是一个判断电话。虽然您从不同的角度提问，但您可能会对此answer about related methods感兴趣。