这是一个理论问题，但是从现在起一段时间以来它一直困扰着我。
背景
假设您为某些高度易变的数据创建了一个很好的RESTful服务。您的用户需要经常查询RESTful服务器才能获得更改。但是，如此多的请求对服务器造成了很大压力。此外，更频繁地查询然后每30秒说一次可能实际上没有多大意义。由于请求是参数化的，因此预先计算everthing并从缓存中提供服务没有多大意义。因此，您需要以某种方式限制用户过于频繁地访问您的资源。
问题
如何通过限制用户来限制用户，而不会破坏不在服务器中保持状态的RESTful范例？
我目前的想法
我的服务现在创建一个帮助程序映射，其中包含当前请求的时间戳以及访问令牌。如果最后一次访问RESTful端点的时间少于30秒，则服务将回答http错误429（请求太多）。这打破了REST。
另类想法
我可以通过私钥加密访问时间。然后，客户端需要发送此密钥以用于下一个请求。我的服务器解密它并决定客户端是否可以执行查询。这似乎是很多开销......
扭
情况变得更复杂，因为我的RESTful服务器中有不同的端点，应该应用不同的访问时间限制。一个请求基本上构建了一个完整的数据库转储 - 这仅供客户获取所有内容的当前状态，但不应该用于一次又一次地查询。
您如何尝试在RESTful服务器中实现此类要求？我应该继续我的方法，虽然它明确地介绍了一个州吗？ 任何人都有加密状态的经验，可以安全地传递而不用担心客户端操作？
这与
不同If REST applications are supposed to be stateless, how do you manage sessions?
上面的问题讨论了RESTful服务器API的一般概念，我确实理解这个概念。这里的问题是关于设计决定，而不是我的设计是否打破REST及其原因的问题。
问题是如何在迄今为止的RESTful服务器中实现限制并保持REST高可伸缩性的好处。有什么最好的做法。我的问题是关于限制工作的具体问题。客户端无法信任以保持状态，因此REST意义上的状态转移将不起作用。别人怎么解决这个问题？