Information given here adequately explains the "Stateless" nature of REST. Even going as far as to say:

For becoming stateless, do not store even authentication/authorization details of client. Provide credentials with the request. Each request MUST stand alone and should not be affected by the previous conversation happened from the same client in past.

With this being said, does rate-limiting violate the statelessness of REST? Or in short, is rate-limiting RESTless?

I'm currently implementing rate-limiting for an API. I'm using a pseudo-sliding window approach. I split time into set intervals (viz. 1 minute) and record how many requests occurred in the last interval and the current interval. I then take a weighted average of the last interval and the current interval based on how far into the current interval I am. This works well.

To make this stateless, I thought of sending the previous interval request count and current interval request count in the JWT for authentication. However, if the user were to request a new token, these would be reset.

Is there any way to truly make rate-limiting stateless? Or does this even violate REST's stateless approach?

  • 5
    API rate limiting is an orthogonal concern. It has nothing to do with REST. Commented Jan 26, 2021 at 14:16

2 Answers 2


Usually, rate-limiting happens at a level lower than the REST API. To see how to implement rate limiting without building it into your API, see: https://stackoverflow.com/questions/131681/how-can-i-implement-rate-limiting-with-apache-requests-per-second These forms of rate-limiting are usually focused on preventing the server from getting overwhelmed or preventing DoS attacks.

In some cases, as was pointed out in the comments below, sometimes rate-limits should be implemented in the API if rate-limiting is part of the way the API needs to work, such as when different rate-limits are associated with differently-priced tiers of access.

  • 1
    Doing it at a lower level is insufficient to enforce API tiers. Say you only allow 100 requests per hour on a free or trial tier, but unlimited for paying customers. That info would be stored behind the API token and be unavailable below the application. However, lower level rate limiting is still necessary for (even accidental) DoS protection. Commented Jan 28, 2021 at 2:24
  • @AlexReinking Good point. Commented Jan 28, 2021 at 14:20

Does API Rate Limiting Violate REST Methodology?


The authoritative description of REST is chapter 5 of Roy Fielding's dissertation. That chapter includes Fielding's definition of the stateless constraint.

each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server

In other words, the server doesn't need to remember any prior messages to correctly interpret the current message.

Consider, for example the LIST command in FTP; LIST with a null argument implies that the user wants a listing of the current working directory or default directory. But to satisfy that request, you would need to be able to determine what the "current working directory" is; which is to say you would need context in the form of session state to know which directory the client is talking about.

In REST, we always include all of the information in the request; there are no "figure it out from previous requests".

Important note: Chapter 6 describes Fielding's experiences in developing the web. It includes a section that describes points where the web's design fails to match up with the REST architectural style.

Fielding's comments about cookies may further your understanding of what he means by "stateless".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.