rest - gRPC 中的分页

Question

我正在使用 gRPC 对呼叫进行分页，并试图找出执行它的选项/近似值。这是一个明智的问题吗？我可以使用哪些资源来做到这一点？

Answer 1

这个问题已经很老了，但我觉得答案中缺少一些东西。

虽然流媒体是恕我直言的首选，但我在某些情况下“传统”分页非常有用。让我们想象一个user服务，它允许 CRUD 访问用户存储并具有一个ListUsers和一个SearchUsersrpc。在这里将结果分块成页面要方便得多。

我个人使用谷歌的方法来解决这个问题：https ://github.com/googleapis/googleapis/blob/master/google/cloud/resourcemanager/v2/folders.proto

Answer 2

谷歌自己写了一个很好的设计文档： https ://cloud.google.com/apis/design/design_patterns#list_pagination

• 在方法的请求消息中定义一个string字段。客户端使用此字段来请求列表结果的特定页面。page_tokenList
• 在方法的请求消息中定义一个int32字段。客户端使用此字段来指定服务器返回的最大结果数。服务器可以进一步限制单个页面中返回的最大结果数。如果 page_size 为 0，服务器将决定返回的结果数。page_sizeList
• 在方法的响应消息中定义一个string字段。此字段表示检索下一页结果的分页标记。如果值为“”，则表示请求没有进一步的结果。next_page_tokenList

关于FieldMask用于部分响应的部分也值得一读，因为这是一种常见的 api 设计模式

Answer 3

分页与分块二进制有效负载非常相似。我在gRPC + Image Upload中的回复可能值得一读。

也就是说，分页可能有不同的权衡，因为它的吞吐量通常要低得多，而且有时使用单独的请求并不难。低吞吐量会阻止流量控制尽快发挥作用，使其发挥作用。对于完全动态的结果（如搜索结果），使用单独的请求更难，但对于更多静态数据（如资源的子项）可能不是什么大问题。

由于 gRPC 流控制可能缓冲过多，因此另一个选项是使用流式传输但引入应用程序级流控制。使用应用程序级别的流控制，您可以在流上使用消息请求您想要多少响应，这并不难使用或实现。一直在讨论原生支持 gRPC 中基于消息的精确流控制（在这种情况下会产生类似的结果），但不清楚是否以及何时会发生。