监视REST资源的更改的RESTful方法是什么? [英] What is a RESTful way of monitoring a REST resource for changes?

问题描述

如果我想监视其他客户端的更改或修改的REST资源，那么最好的方法(也是最RESTful的)是什么?

If there is a REST resource that I want to monitor for changes or modifications from other clients, what is the best (and most RESTful) way of doing so?

我这样做的一个主意是通过提供特定的资源来保持连接打开，而不是在资源不存在时立即返回.例如，给定资源:

One idea I've had for doing so is by providing specific resources that will keep the connection open rather than returning immediately if the resource does not (yet) exist. For example, given the resource:

/game/17/playerToMove

此资源上的"GET"可能告诉我轮到我的对手了.我可能会记下移动编号(例如5)并尝试检索下一个移动，而不是继续轮询此资源以了解何时该移动该移动.

a "GET" on this resource might tell me that it's my opponent's turn to move. Rather than continually polling this resource to find out when it's my turn to move, I might note the move number (say 5) and attempt to retrieve the next move:

/game/17/move/5

在正常" REST模型中，对此URL的GET请求似乎将返回404(未找到)错误.但是，如果相反，服务器将连接保持打开状态，直到我的对手做出举动为止，即:

In a "normal" REST model, it seems a GET request for this URL would return a 404 (not found) error. However, if instead, the server kept the connection open until my opponent played his move, i.e.:

PUT /game/17/move/5

然后服务器可以将我的对手PUT的内容返回到该资源中.这样既可以为我提供所需的数据，又可以在不需要轮询的情况下通知我的对手何时移动.

then the server could return the contents that my opponent PUT into that resource. This would both provide me with the data I need, as well as a sort of notification for when my opponent has moved without requiring polling.

这种方案是RESTful吗?还是违反某种REST原理?

Is this sort of scheme RESTful? Or does it violate some sort of REST principle?

推荐答案

您提出的解决方案听起来像长时间轮询，效果可能很好.

Your proposed solution sounds like long polling, which could work really well.

您将请求/game/17/move/5，并且在完成第5步之前，服务器将不会发送任何数据.如果连接断开或超时，则只需重新连接，直到获得有效的响应即可.

You would request /game/17/move/5 and the server will not send any data, until move 5 has been completed. If the connection drops, or you get a time-out, you simply reconnect until you get a valid response.

这样做的好处是非常快-服务器拥有新数据后，客户端就会获取它.它还可以抵抗断开的连接，并且可以在客户端断开一段时间后起作用(您可以在移动后一个小时请求/game/17/move/5并立即获取数据，然后移动到move/6/上，依此类推)

The benefit of this is it's very quick - as soon as the server has new data, the client will get it. It's also resilient to dropped connections, and works if the client is disconnected for a while (you could request /game/17/move/5 an hour after it's been moved and get the data instantly, then move onto move/6/ and so on)

长时间轮询的问题是每个轮询"都会占用一个服务器线程，这会很快中断像Apache这样的服务器(因为它用完了工作线程，因此无法接受其他请求).您需要专门的Web服务器来处理长时间轮询的请求.Python模块 twisted (一个事件驱动的网络引擎")对此非常有用，但是它比常规的轮询工作更多.

The issue with long polling is each "poll" ties up a server thread, which quickly breaks servers like Apache (as it runs out of worker-threads, so can't accept other requests). You need a specialised web-server to serve the long-polling requests.. The Python module twisted (an "an event-driven networking engine") is great for this, but it's more work than regular polling..

回答您对Jetty/Tomcat的评论时，我对Java没有任何经验，但是似乎他们俩都使用了与Apache类似的工作线程池系统，因此也会遇到同样的问题.我确实找到了此帖子，它似乎完全解决了这个问题(对于Tomcat)

In answer to your comment about Jetty/Tomcat, I don't have any experience with Java, but it seems they both use a similar pool-of-worker-threads system to Apache, so it will have that same problem. I did find this post which seems to address exactly this problem (for Tomcat)

这篇关于监视REST资源的更改的RESTful方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！