如何为需要持久连接的协议设计RESTful HTTP网关？

Question

我正在使用持久的客户端/服务器协议,我需要设计一个RESTful网关.我没有很多设计REST接口的经验,我不明白我应该如何处理(以RESTful方式)维护服务器上持久连接所需的会话ID以及我应该如何将服务器状态表示为资源.

我问这个是因为我不想结束看起来像"RESTful"的RPC-ish结果.

特定于问题的上下文:我想改进现有的ZooKeeper REST网关以支持短暂的节点和监视.客户端连接到服务器时存在临时节点.

谢谢.

Answer 1

我过去这样做的方式遵循“票据”或“收据”模式。REST 服务接受资源请求（报告名称、znode 等）并返回票证。该票证（通常是 UUID 或类似的东西）可用于表示会话。后续请求使用此票证来检查其请求的状态。为了确保票证正确过期，发生以下两种情况之一：您可以使票证超时，或者在收到结果后，客户端必须向服务提供 ACK（确认）。

前任。

请求：GET /zookeeper/znode/ephemeral/foo 响应：1234-1234-1234-1234

请求：GET /zookeeper/status/1234-1234-1234-1234 响应：正在工作（或不可用、被阻止、未就绪或失败...）

请求：GET /zookeeper/status/1234-1234-1234-1234 响应：ACQUIRED（或 AVAILABLE 或 OK 或 SUCCESS 或某些值...）

请求：GET /zookeeper/acknowledge/1234-1234-1234-1234 响应：OK（或 UNKNOWN TICKET 等）

有趣的可管理性消息：

请求：GET /zookeeper/sessions（或 /tickets） 响应：[ 1234, 5668, ... ]

请求：GET /zookeeper/kill/ 响应：OK（或 UNKNOWN 或 FAILED...）

这非常非常有效。但这确实意味着 REST 服务是有状态的，这使得负载平衡等事情变得更加棘手。我使用了一种协议，确保每次响应都会返回服务器 ID，如果客户端收到不同的服务器 ID 和未知的票证，则您会认为您正在交谈的服务已经终止并重新开始。这意味着粘性负载平衡（即循环法在这里不起作用）。REST 服务需要是多线程的，以支持并行执行这些请求，并提供对票证数据库（通常在内存中，同步哈希表数据结构）以及会话/票证超时线程的访问。

希望这可以帮助。