RESTful API必须是无状态的,但是并发性呢？

Question

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

什么是无状态版本？按IP地址哈希,还是根据id随机获取行？

::更新::

"嗯,从客户的角度来看,它必须只是无国籍？

这当然很有意义.我刚刚阅读了一篇关于RESTful API的文章(ibm.com/developerworks/webservices/library/ws-restful),在遇到有关分页的问题之后,我担心我的状态非常好的队列类似于页面递增,但是它们实际上是完全不同的,因为"下一页"在客户端是相对的,而"pop"对于客户端来说总是无状态的:以前弹出的内容并不重要.

谢谢你清理我的脑袋!" - 我

Answer 1

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

1. 完全无状态，并采取“最后的请求获胜”策略。听起来可能有些奇怪，但就可预测性，可伸缩性，代码复杂性以及在客户端和服务器端的实现而言，这可能是最干净的解决方案。它也有很多优先事项：看看Google这样的网站如何通过查询使用start=10第2页，start=20第3页等进行分页。

   当您在页面之间来回导航时，您可能会发现页面内的内容发生了变化，但是那又如何呢？您始终可以获得最新的信息，并且Google可以在许多服务器上处理您的请求，而无需查找会话信息来确定您的上一个查询上下文。

   这种方法的最大优点是服务器实现的简便性。每个请求都可以直接传递到后端的数据层，并且在HTTP级别（通过E-Tags或Last-Modified头）和服务器端（使用诸如memcache之类的缓存）缓存都是绝对成熟的。例）。

2. 进入有状态的状态，并找出一种使服务器为每个API“会话”分配某种类型的每客户端锁定或令牌的方法。这就像尝试用棍子对抗海潮一样，因为您最终将失败并感到沮丧。

   您将如何识别客户？会话密钥？IP地址？他们所使用的套接字的文件描述符（如果您使用的是HTTP之类的传输方式，可以在请求之间关闭连接的话，祝您好运）？您为此选择的详细信息必须保留在服务器端，或者必须在应用程序服务器上使用一些讨厌的旧粘性会话功能（如果这样，如果客户使用的服务器出现故障，天堂可以帮助您的客户端）会话中）。

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

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