问gRPC接口设计建议-处理创建和更新的正确样式

EN

我们正在构建一个新的平台，使用gRPC提供消息层，这将最终公开我们的API所支持的全部功能。

我们正在努力确定命名接口的最佳模式，以避免重复的消息类型，必须一次性处理边缘情况和

我们正在做的一个简单的例子涉及创建、更新和检索用户。下面是我们的服务今天的样子的一个例子：

service Users {
  rpc GetUser(UserRequest) returns (core.user.User) {}
  rpc ListUsers(google.protobuf.Empty) returns (ListUsersResponse) {}
  rpc CreateUser(core.user.User) returns (core.user.User) {}
  rpc UpdateUser(core.user.User) returns (core.user.User) {}
}

message UserRequest {
  string id = 1;
}

message ListUsersResponse{
  repeated core.user.User users = 1;
}

GetUser非常简单--它接收一个ID的简单UserRequest消息，并返回一个用户(从我们的核心包--应用程序中的许多服务将用户消息作为输入，所以我们把它放在一个共享的位置)。

我的问题特别提到创建/更新用户调用，因为不清楚最优解决方案是什么。这两个函数略有不同，主要是在一种情况下，我们已经有了一个用户，因此有一个ID，而在另一种情况下，我们正在创建一个新用户。在Create中，我们可能只有用户可能存在的可用字段的子集，但理想情况下，我们只需要在一个地方维护这个列表，因为它可能会变得相当大。我们可以：

• 对于每个调用，定义一个自定义请求/响应消息，并在其中嵌入任何公共消息。这看起来有点像下面的代码。我担心的是，我们最终的结果是每个调用都有一个消息类型，从可维护性的角度来看，这可能会变得非常繁重。

代码

message CreateUserRequest{ 
  core.User user = 1;
}
message UpdateUserRequest{
  int32 id = 1;
  core.User user = 2;
}

• 我们可以期望/发送公共消息类型，并依赖评论或其他反馈机制来鼓励消费者传递正确的值(我最初的实现演示了什么)。我对这种方法的关注是，我们最终不得不添加大量的验证，以确保它们提供的字段是“正确的”。

我很难在网上找到很多其他人是如何处理这些问题的例子。我提供的示例相当简单，但您可以想象，在整个项目中，我们都会遇到类似的问题。我想看到的是一个非常复杂的gRPC接口的例子，有人在实践中这样做过，或者仅仅是来自那些广泛使用它的人的反馈，以了解他们认为界面设计中哪些模式最有效。

谢谢!