api - RESTful API 必须是无状态的，但是并发呢？

Question

我很好奇我是如何解决 RESTful API 的并发问题的。更具体地说，我有一组需要手动检查和更新的对象，例如需要手动更新列的行数；但是，如果我向许多客户端开放 API，他们都会从上到下抓取这些项目，因此许多用户将同时填充同一行的列。我希望没有冲突，简单的、有状态的方法是将项目转储到服务的队列中，并在人们请求时将它们弹出。

什么是无状态版本？按 IP 地址散列，还是根据 id 随机抓取行？

::更新::

“嗯，所以从客户端的角度来看，它必须是无状态的吗？

这当然很有意义。我刚刚读了一篇关于 RESTful API 的文章 (ibm.com/developerworks/webservices/library/ws-restful)，在遇到有关分页的内容后，我担心我的有状态队列类似于按页面递增，但是它们实际上完全不同，因为“下一页”在客户端是相对的，而“pop”对于客户端始终是无状态的:之前弹出的内容无关紧要。

谢谢你让我清醒!”-我

Answer 1

您可以采用两种基本方法:

完全无状态，并采用“最后一个请求获胜”的策略。尽管听起来很奇怪，但很可能是 最干净的解决方案 在客户端和服务器端的可预测性、可伸缩性、代码复杂性和实现方面。它也有很多优先级:看看像 Google 这样的网站如何使用 start=10 对查询进行分页。第 2 页，start=20对于第 3 页等。

当您在页面之间来回导航时，您可能会发现页面内的内容会发生变化，但那又怎样？您总能获得最新信息，而且 Google 可以在其众多服务器中的任何一个上处理您的请求，而无需查找您的 session 信息来确定您上次查询的上下文是什么。

这种方法的最大优点是服务器实现的简单性。每个请求都可以直接传递到后端的数据层，并且在 HTTP 级别(通过 E-Tags 或 Last-Modified header )和服务器端(使用类似 memcache 的东西，对于例子)。

转到有状态，并找出一种方法让您的服务器为每个 API“ session ”发放某种每个客户端的锁或 token 。这就像试图用一根棍子对抗大海的潮汐，因为你最终会失败和沮丧。

您将如何识别客户？ session key ？ IP地址？他们所在的套接字的文件描述符(如果您使用像 HTTP 这样的传输，可以在请求之间关闭连接，那么祝您好运...)？您为此选择的详细信息必须保留在服务器端，否则您必须在您的应用服务器上使用一些令人讨厌的旧粘性 session 功能(如果是这样，如果他们使用的服务器出现故障，请天堂帮助您的客户 session 中)。

您将如何处理不正常消失的 API 客户端？您是否会通过让收割者线程清理空闲的来自动超时他们的 session 锁？那是更多的代码、更多的复杂性和更多隐藏错误的地方。如果 API 客户端从长时间的空闲时间回来并尝试重新使用过期的锁，那么应该如何构建客户端应用程序来处理这种情况？

我可以继续，但希望你能明白我的意思。选择选项 1，然后无状态。否则，您最终将尝试在服务器端跟踪客户端状态。 唯一应该跟踪客户端状态的是客户端本身。