java - 如何忽略不耐烦用户的多次点击？

Question

我有一个查询来回答远程客户的标准请求。标准是指它不从服务器外部获取任何参数。每当 任何人向 URL 提交请求，比如 http://www.example.com/query ，她/他在响应正文中获取 reply.xml 的内容， 取决于当时数据库提供的内容。 reply.xml 的内容只在服务器上的数据库内容中发生变化，而不会在任何外部发生变化 比如谁做查询，在哪个输入上等等，因此不接受客户端的参数。我什至不检查任何身份验证——我们将一切都留给了防火墙。

所以我写了一个@POST 方法，比如query() 来调用发布到http://www.example.com/query 的请求。 , 并交付结果。我使用了 Jersey 并且一切正常，除了

请求应该是跨时间排他的。 也就是说，一次应该处理一个请求——随后的用户点击应该收到一条 HTTP 状态为 309 的消息，除非服务器没有运行由我的方法 query() 调用的查询进程.

如何实现？我尝试让 query() 服务于 @PUT 而不是 @POST 响应，并得到了相同的结果。

也许是关于该主题的幼稚问题。不过对Restful服务不是很熟悉。

我可以通过在 token 上线程化来控制一次只运行一个查询并使同时请求接收 HTTP 309 来做到这一点。但是必须有更好、更简单的方法在服务器上实现这一点。

我使用的是 Tomcat 8，Jersey 1.19。

TIA。

注意:我读过PUT vs POST in REST在其他一些有用的讨论中。

//=====================

编辑:

哪个用户提交查询在任何时候都没有任何区别。

假设 userA 提交了一个查询。当该查询仍在运行时，即在 query() 将响应返回给 userA 之前，userB 提交了一个查询。 userB 应该得到一个 309——只是因为当时正在处理一个查询。

无论是 userA = userB 还是 userA <> userB 在这里都不重要，应该只返回 309因为在一个已经运行的时候有一个查询请求。这是用户唯一一次收到 309。

//=========================================== =

编辑-2:

我知道带有并发控制的解决方案。我猜有人在使用 Restful 功能。这是一个相当学术的问题。

Answer 1

• @Koos Gadellaa 说客户端应该阻塞是正确的 第二个请求直到响应到达。让我解释一下为什么这是最好的做法。 在架构上，它与关注点有关。服务器不知道为什么两个请求并行到达。因此，它依赖于带外知识来知道并行请求是不好的。任何带外知识都会产生耦合，这意味着如果您更改系统的一部分的工作方式，则必须更改另一部分。 RESTful 架构很受欢迎，因为它们减少了耦合。如果同一个用户登录到两个客户端，那么系统就会崩溃。您永远不想构建具有这种客户端-服务器耦合类型的系统。

• 关于服务器的责任，良好的编码实践开始发挥作用，最好的办法是确保服务不会受到来自用户的多个并行请求的阻碍。缓存可能是你的 friend 。根据查询参数，可以将响应写入磁盘上的缓存文件。客户端将始终使用 HTTP 303 重定向到缓存文件 URL。可以使用 304 Not Modified，这样客户端就不必下载两次答案。在这种情况下，唯一的带外知识是正确实现 HTTP 规范，该规范规范明确且稳健。

• 如果服务过载，相应的响应代码似乎是 503。

  10.5.4 503 Service Unavailable

  The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

       Note: The existence of the 503 status code does not imply that a
       server must use it when becoming overloaded. Some servers may wish
       to simply refuse the connection.
  

• 因为你从 my response here 引导我来到这里，看起来您想知道正确的 RESTful 方法。这将比上面的解决方案更复杂，我猜你不想走这条路，但就是这样。

  If the server needs to communicate to the client that a request is being performed and when it completes, then resources need to be created for those concepts. This feels weird because they concepts exist in HTTP and it is odd to reimplement them at a higher level (architectural smell).

  1. The client would POST a Request or Query resource to the server. This resource would have a Response property that is empty and a Status property which is empty. The server would respond with a body that has the Status property set to "processing".
  2. The client would then perform GETs to this resource (possibly use long-polling here) to check for updates.
  3. When the response has been created, the Response property would then link to a response resource or have the response embedded.

  这种方法使用资源来传达正在发生的事情。因此，唯一的带外知识是资源的有效状态。