所以我现在正在和一位同事集思广益，关于后端API，我们正在进行概念设计。这是一个非常简单的读取API，客户端从服务器请求某些数据，服务器回复该数据。
我们现在只是集思广益，而且出现的一个“想法”是客户端和服务器之间的一种中介或抽象层。主要原因是服务器上的状态很少发生变化，但客户端需要不断检查它。
所以，不要有这样的事情：
客户＆lt; - ＆gt;服务器
你有：
客户＆lt; - ＆gt;中间人＆lt; - ＆gt;服务器
中介将是一个超级轻量级服务，能够快速从客户端部署请求。基本上它会对服务器进行缓存请求，如果服务器上的状态确实发生了变化，服务器会通知中介，并且在将来的请求中，中介会响应更新的数据。
所以，对我的实际问题。我的实际问题是，这个模式是否有名称，是否相对常见（或不常见）？是否有实现这样的服务或示例？有没有可以帮助实现这种模式的服务？例如，我花了一些时间研究ZeroMQ，但它似乎只是用于消息传递，并且服务没有办法缓存数据或以其他方式管理中介，就像我想象的那样。
对不起，这一切都是模糊的，但这真的只是我们正在做的一些头脑风暴。我大多只是希望能找到这个概念或模式的名称，以便我可以挖掘和做更多的研究，了解利弊等。
答案 0 :(得分：0)
我认为它刚刚称为客户端/服务器架构。但是有一个建议。客户端和服务器之间没有这个“中间服务器”，为什么不在只有更新可用的情况下让服务器向所有连接的客户端广播？这样，如果发生任何变化，您的客户不会不断询问您的服务器。
答案 1 :(得分：0)
我将其视为ClientProxy。
从概念上讲，您真正想要的是服务器告诉客户端一些东西，但无论出于何种原因，您都无法将这些事件传递给客户端。因此，您创建服务器将事件发送到的代理服务器。然后ClientProxy和真实客户端以他们自己的方式进行通信，在这种情况下通过轮询。
顺便说一下，请注意Comet等技术允许浏览器客户端接收推送事件。
答案 2 :(得分：0)
在您提出的架构中，听起来“中介”只是一个数据缓存。当服务器检测到数据更新时，他联系Intermediary以更新其缓存数据。客户联系中介，该中介能够快速回复缓存的答案。
如果上述假设是正确的，为什么不简单地教服务器缓存数据？这样，只要客户端请求它，它就会快速响应（返回缓存数据）。当数据更新时，它可以立即使自己的缓存无效。这似乎是一个更容易实现和维护的解决方案。
您是否有理由要求中介成为其独立且独特的实体？