这是一个理论问题，但从一段时间以来一直困扰着我。
背景
假设您为一些高度易变的数据创建了一个不错的 RESTful 服务。您的用户将需要经常查询 RESTful 服务器以获取更改。然而，如此多的请求给服务器带来了很大的压力。此外，更频繁地查询然后每 30 秒说一次实际上可能没有太大意义。由于请求是参数化的，因此预先计算所有内容并从缓存中提供服务没有多大意义。因此，您需要以某种方式限制用户过于频繁地访问您的资源。
问题
如何在不破坏不在服务器中保持状态的 RESTful 范式的情况下通过限制用户的请求来限制用户？
我现在的想法
我的服务现在创建了一个辅助映射，其中包含当前请求的时间戳和访问令牌。如果最后一次访问 RESTful 端点的时间少于 30 秒，则服务会以 http 错误 429（请求过多）进行响应。这打破了 REST。
另类的想法
我可以通过私钥加密发送访问时间。然后，客户端需要将此密钥一起发送以进行下一个请求。我的服务器对其进行解密并决定客户端是否可以执行查询。这似乎是很多开销......
捻
情况变得更加复杂，因为我的 RESTful 服务器中有不同的端点，应该应用不同的访问时间限制。一个请求基本上构建了一个完整的数据库转储 - 这只是为了让客户获取所有内容的当前状态，但不应该用于一次又一次的查询。
您将如何尝试在 RESTful 服务器中实现这样的需求？我是否应该继续我的方法，尽管它清楚地引入了一种状态？任何人都有加密状态性能的经验，可以安全地传递而不必担心客户端操纵？
这不同于
如果 REST 应用程序应该是无状态的，那么您如何管理会话？
上面的问题讨论了 RESTful 服务器 API 的一般概念，我认为我确实理解了这个概念。这里的问题是关于设计决定，而不是我的设计是否破坏 REST 以及为什么的问题。
问题是如何在迄今为止的 RESTful 服务器中实现节流并保持 REST 的高可扩展性的好处。什么是最佳实践。我的问题是关于节流工作的具体问题。不能信任客户端保持状态，因此 REST 意义上的状态传输将不起作用。其他人如何解决这个问题？