在 SOA 中，我们不应该在客户端和服务器之间构建或保持状态(或设计依赖关系)。这是明白的。但是，在客户端想要使用可能返回开放式“行”数量的实时服务的情况下，可以遵循哪些模式？
Web 应用程序，类似于 SOA，但允许状态( session )已经通过分页解决了这个问题。分页要求(在大多数情况下，尤其是使用 SQL)服务器保存数据并且客户端以块的形式请求数据。
如果我们在何处考虑 Web 服务的类似分页的场景，这些将遵循哪些模式仍然允许遵守(或尽可能接近)SOA 的原则。
给思考者的一些规则:
1)由SQL数据库支持(因此选择集中没有行号的概念)
2)在分页期间不要跳过一行或在集合中复制一行很重要
3) 其他客户端可以随时在数据库中插入和删除数据
4)无需将数据集视为实时(可更新)数据集
就我个人而言，我认为上面的 1 和 2 已经通过用需求限制解决方案空间来拼写我们的解决方案。
我提出的解决方案会将数据(与选择的一样多)存储在只读存储/缓存中，可以在其中分配结果集中的行号，并允许在此数据快照上进行分页。我有存储快照的基础设施(服务器、外部缓存、memcached 或 ehcache - 这必须扩展得相当大)。此类查询的结果将是快照 ID，客户端可以使用快照 API(Web 服务)和快照 ID 从快照中检索数据。在 x 是合理的时候，结果将以只读、只转发的方式处理 x 记录。
竞争的想法和想法，批评或赞誉将不胜感激。
最佳答案
Web 服务中的分页结果实际上很容易实现。
您所要做的就是向 Web 服务调用添加两个参数:页面大小、页码。
页面大小是要包含在页面中的结果数。页码是您要查找的结果页码。
然后，您的 Web 服务返回到数据库(或缓存)，检索结果，找出适合请求页面的结果，并仅返回这些结果。
然后，客户端必须对他们想要从服务中获得的每页结果发出一个请求。
关于web-services - SOA/Web 服务分页，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3094241/