对于需要长连接的协议，如何设计RESTful HTTP网关？

Question

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

我之所以这样问，是因为我不想最终得到一个看起来像"RESTful“的RPC结果。

具体问题背景:我想改进现有的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响应:已获取(或AVAILABLE或OK或SUCCESS或某些值...)

请求: GET /zookeeper/acknowledge/1234-1234-1234-1234响应: OK (或未知工单等)

有趣的可管理性信息：

请求: GET /zookeeper/sessions (或/tickets)响应: 1234,5668，...

请求: GET /zookeeper/kill/ Response: OK (或未知或失败...)

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

希望这能有所帮助。