google.protobuf.Empty对向后兼容有害吗?

时间:2018-06-22 18:32:34

标签: protocol-buffers grpc

google.protobuf.Empty的{​​{3}}状态:

  

您可以重复使用的通用空消息,以避免定义重复的消息    API中的空消息。一个典型的例子是将其用作请求    或API方法的响应类型。

我一直在内部提倡使用空消息包装器,以保持向后兼容性。例如,假设我们有一个FooService

service Foo {
    rpc List(google.protobuf.Empty) returns (ListResponse) {}
}

message ListResponse {
    repeated Foo results = 1;
}

message Foo {...}

如果将来需要在此列表请求中添加分页,则需要引入请求包装:

message ListRequest {
    int limit = 1;
    int offset = 2;
}

,然后更新rpc签名:

rpc List(ListRequest) returns (ListResponse) {}

这是向后不兼容的更改,还是protobuf格式可以妥善处理此问题?

1 个答案:

答案 0 :(得分:1)

有线格式可以很好地处理此问题。但是,大多数使用gRPC存根的代码都会中断,因为类型安全的语言会注意到不兼容的类型。

如果您认为可能永远需要字段,请继续针对该情况发出特殊消息,即使该消息为空。如有疑问,请这样做。如果您确信您将不需要任何字段(“ delete”的响应消息是一个常见示例),则可以使用<body> <div class="headerspan"> <div class="headercontainer"> <div class="section group"> <div class="col span_6_of_12"> <img class="responsiveimg" src="images/logo.png"> </div> <div class="col span_6_of_12 phonenumber"> Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text </div> </div> </div> </div> </body>

我在Modifying gRPC Services Over Time演讲中提到了这种特殊情况。可以使用幻灯片和视频录制。

相关问题