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

google.protobuf.Empty 的 spec 说明:



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

最佳答案

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

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

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

关于protocol-buffers - google.protobuf.Empty 向后兼容是否危险？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/50993815/