我正在这里寻找一些建议。用例是一种联网设备（如路由器），其通过gRPC执行联网操作。
让我们说有“ n”个模型对象，例如路由器，接口，路由配置对象（例如OSPF等）。每个联网操作（例如最终在一个或多个模型对象上都启用CRUD）。
现在，通过gRPC服务定义此选项时，似乎有2个选项：
定义通用gRPC RPC，例如“ SET”和“ GET”。该参数将是对象和操作的列表。像SET（（router，update），（interface，update）..
定义非常特定的RPC。像“ setInterfaceProperty_x”，“ createOSPFInstance”一样。.这样的RPC可能很多。
使用＃2，我们正在RPC本身中构建应用程序智能。每个新功能都可能需要此服务提供新的RPC。
在＃1中，RPC是手段，但情报在于在上下文中使用RPC的应用程序。 RPC列表将很少，并且不会随时间变化。
首选方法是什么？通用RPC（并保持很少）或具有数十（或更多）由操作驱动的RPC？我看到一些开源项目（例如P4Runtime）采用方法＃1。
感谢您的宝贵时间。如果需要，我可以提供更多信息。
答案 0 :(得分：0)
您应该使用选项＃2。这将使您的接口合同处于原始状态，而不是您的应用程序中。您选择选项＃2可能会很麻烦或不被支持，从而给自己留下很多门户：
InterfaceProperty，而是将其移动到名为BetterInterfaceProperties的新字段中。选项1会迫使您保留旧字段，而选项2则使您可以重新解释调用并做正确的事。publicProperty，但是只有管理员可以设置dangerousProperty。通过将所有字段分组到一个调用中（如＃1中所示），您的呼叫者必须重新解释错误消息，而在选项＃2中，更清楚地说明了授权失败的原因。getSpecificProperty之类的方法比getFullObject做的工作要少得多。随着数据模型变得越来越复杂，您将不得不在返回消息中包含越来越多的数据。即使呼叫者只关心一件事，他们也必须等待所有这些。考虑一个数据库应用程序。数据库可能必须执行几个不必要的查询才能填写客户端永远不会读取的字段。使用＃1是有原因的，但是在您确定哪些属性组合在一起并且在逻辑上是单个RPC之前，它们没有什么价值。 （例如Get）