在gRPC之上对REST Web服务进行版本控制

Question

我已经使用带有协议缓冲区的gRPC实现了一个API服务，然后使用grpc-gateway将其公开为一组REST Web服务。

现在我已经到了我必须维护不同版本的API的地步，我被卡住了。

在我的proto文件中，我有一个像这样定义的处理程序

rpc MerchantGet (MerchantRequest) returns (MerchantResponse) {
    option (google.api.http) = {
        get: "/v1.1.0/myapi/merchant/{MerchantID}"
    };
}

在我的Go代码当然我有一个函数，qazxsw poi，qazxsw poi对qazxsw poi的动作被映射。

现在，假设我想为MerchantGet方法添加更多功能并发布新版本。我打算按照GET保持向后兼容性，所以如果我理解正确，这意味着我可以对我的/v1.1.0/myapi/merchant/{MerchantID}方法进行基础更改并让它取代旧方法，只要它不需要来自第三方的不同输入（MerchantGet）或更改发送给第三方（Semantic Versioning Specification）的响应，而不是在响应结尾添加其他字段。 （如果我在这个假设中错了，请纠正我）。

我的问题是，如何编写proto处理程序来为不同版本的端点提供方法？想到的一个选项看起来如下：

MerchantGet

但肯定这不是实现这一目标的惯用方法吗？它当然不是很优雅，因为每个新的次要版本或补丁，我都必须将这些MerchantRequest扩展到我的每个方法（上面我只使用一种方法作为例子）。

Answer 1

从SemVer规范：

给定版本号MAJOR.MINOR.PATCH，增加：

1. 进行不兼容的API更改时的MAJOR版本，
2. 当您以向后兼容的方式添加功能时的MINOR版本，以及
3. 当您进行向后兼容的错误修复时，PATCH版本。

预发布和构建元数据的附加标签可用作MAJOR.MINOR.PATCH格式的扩展。

与REST端点版本控制相关的唯一版本是MAJOR版本，因为所有MINOR和PATCH更改必须向后兼容。

回答你的问题： 仅使用REST URI中的主要版本号。从REST的角度来看，其余部分是一个实现细节。

那么，您的原型服务将是：

MerchantResponse