Does API Rate Limiting Violate REST Methodology?

Question

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?

Answer 1

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.

Answer 2

Does API Rate Limiting Violate REST Methodology?

No.

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".