1

This is a bit of a theory question, but it was bugging me since some time now.

Background

Suppose you created a nice RESTful service for some highly volatile data. Your users will need to query the RESTful server quite often to get the changes. However, so many requests stress the server quite hard. Also it may make actually not too much sense to query more often then say once per 30 sec. Since the request is parameterised, it would not make much sense to precalculate everthing and serve from the cache. So you need to somehow restrict the user from accessing your resource too often.

The question

How can you restrict a user by throttling down his requests without breaking the RESTful paradigm of not keeping state in the server?

My current thinking

My service now creates a helper map that holds a timestamp of the current request together with the access token. The service answers with an http error 429 (too many requests) if the last access to the RESTful endpoint was less than 30 sec ago. This breaks REST.

Alternative idea

I could send the access time along encrypted by a private key. The client would then need to send this key along for the next request. My server decrypts it and decides if the client can perform the query yet. This is a lot of overhead it seems...

Twist

The situation gets more complicated, since I have different endpoints in my RESTful server for which different access time restrictions should apply. One request basically builds a complete database dump - this is only meant for the customer to get the current state of everything, but it should not be used to query again and again.

How would you try to implement such a requirement in a RESTful server? Should I continue with my approach although it clearly introduces a state? Anyone has experience with the performance of encrypted state that can be safely passed around without fear for client side manipulation?

This is different from

If REST applications are supposed to be stateless, how do you manage sessions?

The above question discusses the general idea of RESTful server APIs and I do understand the concept all right I think. The question here is about a design desicion, not the question if my design breaks REST and why.

The question is how to implement throttling in a so far RESTful server and keep the benefits of high scalability of REST. What are the best practices for that. My question is specific about getting throttling to work. The client can't be trusted to keep the state, so that state transfer in the sense of REST will not work. How do others solve this?

Community
  • 1
  • 1
luksch
  • 11,497
  • 6
  • 38
  • 53
  • Thoughts: Distribute the load so the server(s) can handle it. Use a push instead of a pull scheme. –  Jul 08 '15 at 19:18
  • thanks for the input. Pushing is unfortunately not possible in this particular setup. I have made good experiences with websockets in the past, but it does not fit the bill for this project for other reasons. The client needs to use a simple API over http(s). Multiple servers would just increase cost on my side and no matter how many servers I will use, in the end you can overuse them. My time restrictions make also sense data-wise, so allowing more frequent requests does not increase service quality. – luksch Jul 08 '15 at 20:02
  • possible duplicate of [If REST applications are supposed to be stateless, how do you manage sessions?](http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions) – Eric Stein Jul 09 '15 at 16:16
  • @EricStein I did see that question and it is not concerned about throttling but general session state. i think this is different enough to justify the own question. – luksch Jul 09 '15 at 16:26
  • 1
    Up to you. The way I read the question, you're asking "how do I manage throttling without tracking session state". You clearly can't rely on anything coming from the client to keep track of their request frequency, so it has to be on the server. That question talks about how to do it correctly. – Eric Stein Jul 09 '15 at 16:54

0 Answers0