如何为需要持久连接的协议设计一个RESTful HTTP网关？
我正在使用持久的客户端/服务器协议，并且需要设计一个 RESTful 网关。我没有太多设计 REST 接口的经验，并且不明白应该如何（以 RESTful 方式）处理在服务器上维护持久连接所需的会话 ID，以及如何将服务器状态表示为资源。
我问这个问题是因为我不想最终得到看起来“RESTful”的 RPC 式结果。
问题具体上下文：我想改进现有的 ZooKeeper REST 网关以支持临时节点和监视。当客户端连接到服务器时，存在临时节点。
谢谢。
I'm working with a persistent client/server protocol and I need to design a RESTful gateway. I don't have a lot of experience designing REST interfaces and I don't understand how I should handle (in a RESTful way) the session IDs needed to maintain persistent connections on the server and how I should represent server state as resources.
I'm asking this because I don't want to end-up with a RPC-ish result that looks "RESTful".
Problem specific context: I want to improve the existing ZooKeeper REST gateway to support ephemeral nodes and watches. An ephemeral node exists while the client is connected to the server.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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/
响应：好的（或未知或失败...）
这非常非常有效。但这确实意味着 REST 服务是有状态的，这使得负载平衡等事情变得更加棘手。我使用了一种协议，可确保每次响应都会返回服务器 ID，如果客户端收到不同的服务器 ID 和未知的票证，则您会认为正在交谈的服务已终止并重新开始。这意味着粘性负载平衡（即循环法在这里不起作用）。 REST 服务需要是多线程的，以支持并行执行这些请求，并提供对票证数据库（通常在内存中，同步哈希表数据结构）以及会话/票证超时线程的访问。
希望这有帮助。
The way in which I've done this in the past follows a "ticket" or "receipt" pattern. The REST service accepts requests for a resource (a report name, a znode, etc.) and returns a ticket. This ticket (usually a UUID or something similar) can be used to represent a session. Subsequent requests use this ticket to check on the status of their requests. To ensure proper expirey of tickets, one of two cases occurs; you can time out tickets or, upon receiving a result, the client must provide an ACK (acknowledgment) back to the service.
ex.
Request: GET /zookeeper/znode/ephemeral/foo
Response: 1234-1234-1234-1234
Request: GET /zookeeper/status/1234-1234-1234-1234
Response: WORKING (or UNAVAILABLE or BLOCKED or NOTREADY or FAILED...)
Request: GET /zookeeper/status/1234-1234-1234-1234
Response: ACQUIRED (or AVAILABLE or OK or SUCCESS or some value(s)...)
Request: GET /zookeeper/acknowledge/1234-1234-1234-1234
Response: OK (or UNKNOWN TICKET, etc.)
Interesting manageability messages:
Request: GET /zookeeper/sessions (or /tickets)
Response: [ 1234, 5668, ... ]
Request: GET /zookeeper/kill/
Response: OK (or UNKNOWN or FAILED...)
This has worked very, very well. This does mean, however the REST service is stateful which makes things like load balancing trickier. I've used a protocol that ensures a server ID is returned with each response and if the client receives a different server ID and an UNKNOWN ticket, you assume the service you were talking to has died and start over. This implies sticky load balancing (i.e. round-robin wouldn't work here). The REST service needs to be multi-threaded to support performing these requests in parallel and provide access to a ticket database (usually in memory, sync'd hashtable data structure) as well as a session / ticket timeout thread.
Hope this helps.