请求/响应模式中客户端和服务器之间典型的抽象层类型是什么？
因此，我现在正在与一位同事就我们正在构思的后端 API 进行集思广益。这是一个非常简单的读取 API，客户端向服务器请求某些数据，服务器用该数据进行回复。
目前我们只是在集思广益，提出的一个“想法”是在客户端和服务器之间建立一种中间层或抽象层。主要原因是服务器上的状态很少改变，但客户端需要不断检查它。
所以，不要有这样的东西：
Client <-->服务器
你有：
客户端<-->中介<-->服务器
其中中介将是一个超轻量级服务，能够快速处理来自客户端的请求。基本上，它会缓存对服务器的请求，如果服务器上的状态确实发生变化，服务器将通知中介，并且在将来的请求中，中介将使用更新的数据进行响应。
那么，对于我的实际问题。我的实际问题是，这种模式有名称吗？它相对常见（或不常见）吗？是否有实现类似功能的服务或示例？是否有服务可以帮助人们实现这种模式？例如，我花了一些时间研究 ZeroMQ，但它似乎只是用于消息传递，并且该服务无法像我设想的那样缓存数据或以其他方式管理中介上的状态。
抱歉，这确实很模糊，但这确实只是我们正在做的一些头脑风暴。我主要只是希望我能为这个概念或模式找到一个名称，以便我可以挖掘并做更多研究，了解其优点和缺点等。
So I'm brainstorming some stuff with a coworker right now with regards to backend API we're in the process of concepting out. It's a pretty straightforward read API, where a client requests certain data from a server and a server replies with that data.
We're just brainstorming ideas at the moment, and one "idea" that came up was a sort of intermediary or abstraction layer between the client and the server. The main reason for this is that the state on the server very rarely changes, but the client needs to check it constantly.
So, rather than having something like this:
Client <--> Server
You'd have:
Client <--> Intermediary <--> Server
Where the intermediary would be a super lightweight service capable of fielding requests quickly from the client. Basically it would sort of cache requests to the server, and if state did happen to change on the server, the server would notify the intermediary and in future requests the intermediary would respond with the updated data.
So, to my actual question. My actual question is, is there a name for this pattern, and is it relatively common (or uncommon)? Are there services or examples where something like this is implemented? Are there services that help one implement such a pattern? For example, I spent a bit of time investigating ZeroMQ, but it would seem that it used simply for message passing, and there is no way for the service to cache data or otherwise manage state on an intermediary like I'm envisioning.
Sorry this is all admittedly vague, but it truly is just some brainstorming we're doing. I'm mostly just wishing I could find a name for this concept or pattern so that I can dig and do more research, understand the pros and cons, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为它只是称为客户端/服务器架构。不过是一个建议。与其在客户端和服务器之间放置这个“中间服务器”，为什么不让服务器在有可用更新时向所有连接的客户端广播呢？这样，您的客户端就不会不断询问您的服务器是否有任何更改。
I think its just called client/server architecture. A suggestion though. Instead of having this "intermediate server" in between the client and the server, why don't you just have the server broadcast out to all the connected clients whenever an update is available? That way your clients are not continually asking your server if anything changed.
我将其视为 ClientProxy。
从概念上讲，您真正想要的是服务器告诉客户端一些信息，但无论出于何种原因，您都无法将这些事件传递给客户端。因此，您需要创建一个服务器将事件发送到的代理。然后 ClientProxy 和真实的 Client 以自己的方式进行通信，在本例中是轮询。
顺便请注意，有些技术（例如 Comet）允许浏览器客户端接收推送事件。
I see this as a ClientProxy.
Conceptually what you really want is for the Server to tell the Clients something, but for whatever reason you can't deliver those events to the Client. So instead you create a Proxy that the server sends the events to. Then the ClientProxy and the real Client communicate in their own way, in this case by polling.
In passing, note that there are technologies such as Comet that allow Browser clients to receive push events.
在您提出的架构中，听起来“中介”只是一个数据缓存。当Server检测到数据更新时，他联系Intermediary来更新他缓存的数据。客户联系中介，中介能够通过缓存的答案快速做出响应。
如果上面的假设是正确的，为什么不简单地教Server缓存数据呢？这样，每当客户端请求时，它都会快速响应（返回缓存的数据）。并且当数据更新时，它可以立即使自己的缓存失效。看起来这将是一个更容易实施和维护的解决方案。
您是否有理由需要中介机构成为自己独立且独特的实体？
In your proposed architecture, it sounds like "Intermediary" is simply a data cache. When Server detects data updates, he contacts Intermediary to update his cached data. Clients contact Intermediary, which is able to quickly respond with cached answers.
If the above assumption is correct, why not simply teach Server to cache data? That way, it will respond quickly (return cached data) whenever the client requests it. And when data is updated, it can instantly invalidate its own cache. It seems like that would be a much more easily-implemented and -maintained solution.
Are there reasons you need Intermediary to be its own separate and distinct entity?