protocol-buffers - google.protobuf.Empty 向后兼容是否危险？

Question

spec为 google.protobuf.Empty状态:

A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method.

我一直在内部提倡使用空消息包装器，以保持向后兼容性。例如，假设我们有一个 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 格式可以优雅地处理这个？

Answer 1

有线格式很好地处理了这个问题。但是，大多数使用 gRPC stub 的代码都会中断，因为类型安全语言会注意到不兼容的类型。

如果您认为您可能需要字段，请继续为该案例制作一条特殊消息，即使它是空的。如果有疑问，就去做。如果你确信你永远不需要任何字段(“删除”的响应消息是一个常见的例子)，那么使用 Empty很好。

我在我的 Modifying gRPC Services Over Time 中提到了这个具体案例讲话。提供幻灯片和视频录制。