我正在使用持久的客户端/服务器协议，我需要设计一个 RESTful 网关。我没有太多设计 REST 接口的经验，我不明白我应该如何处理（以 RESTful 方式）在服务器上维护持久连接所需的会话 ID，以及我应该如何将服务器状态表示为资源。
我问这个是因为我不想最终得到一个看起来“RESTful”的 RPC-ish 结果。
问题特定上下文：我想改进现有的 ZooKeeper REST 网关以支持临时节点和监视。当客户端连接到服务器时，存在一个临时节点。
谢谢。
【问题讨论】：
我过去这样做的方式遵循“票证”或“收据”模式。 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 和一个 UNKNOWN 票证，您假设您正在与之交谈的服务已经死亡并重新开始。这意味着粘性负载平衡（即循环在此处不起作用）。 REST 服务需要是多线程的，以支持并行执行这些请求并提供对票证数据库（通常在内存中，同步的哈希表数据结构中）以及会话/票证超时线程的访问。
希望这会有所帮助。
【讨论】：