google.protobuf.Empty对向后兼容有害吗? [英] Is google.protobuf.Empty dangerous for backwards compatibility?

问题描述

google.protobuf.Empty状态的规范 :

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

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:

I've been advocating internally to use an empty message wrapper instead, to preserve backwards compatibility. For instance, let's say we have a FooService:

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

message ListResponse {
    repeated Foo results = 1;
}

message Foo {...}

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

If in the future we need to add paging to this list request, we'd need to introduce a request wrapper:

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

，然后更新rpc签名:

and then update the rpc signature:

rpc List(ListRequest) returns (ListResponse) {}

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

Is this a backwards-incompatible change, or can the protobuf format handle this gracefully?

推荐答案

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

The wire format handles this gracefully. However, most code using the gRPC stubs will break as type-safe languages will notice the incompatible types.

如果您认为自己可能永远需要字段，请继续为该情况发出特殊消息，即使该消息为空.如有疑问，请这样做.如果您有信心不需要任何字段("delete"的响应消息是常见示例)，则使用Empty很好.

If you think you may ever need fields, go ahead and make a special message for that case, even if it is empty. If in doubt, do it. If you are confident you will never need any fields (the response message of "delete" is a common example), then using Empty is fine.

我在随时间修改gRPC服务.可以使用幻灯片和视频录制.

I mentioned this specific case in my Modifying gRPC Services Over Time talk. Slides and video recording are available.

这篇关于google.protobuf.Empty对向后兼容有害吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！