rest - 如何为需要持久连接的协议(protocol)设计 RESTful HTTP 网关？

Question

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

我问这个是因为我不想最终得到一个看起来“RESTful”的 RPC-ish 结果。

问题特定上下文:我想改进现有的 ZooKeeper REST 网关以支持临时节点和 watch 。当客户端连接到服务器时，存在一个临时节点。

谢谢。

Answer 1

我过去这样做的方式遵循“票证”或“收据”模式。 REST 服务接受对资源(报告名称、znode 等)的请求并返回票证。此票证(通常是 UUID 或类似的东西)可用于表示 session 。后续请求使用此票证检查其请求的状态。为确保票证正确过期，会出现以下两种情况之一；您可以超时票证，或者在收到结果后，客户端必须向服务提供 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 服务是有状态的，这使得负载平衡之类的事情变得更加棘手。我使用了一个协议(protocol)来确保每个响应都返回一个服务器 ID，如果客户端收到不同的服务器 ID 和一个 UNKNOWN 票证，您假设您正在与之交谈的服务已经死亡并重新开始。这意味着粘性负载平衡(即循环在此处不起作用)。 REST 服务需要是多线程的，以支持并行执行这些请求并提供对票证数据库(通常在内存中，同步的哈希表数据结构中)以及 session /票证超时线程的访问。

希望这可以帮助。