Accelerating REST: Rate-limiting

I took a trip with my son last weekend to Fort Worth. If you haven’t met him, he is energetic, curious, and quite a bit more vocal than I am. His curiosity, while a good thing, sometimes gets to be a bit much. I find myself trying to divert his requests to other adults in the room, or replying with “not right now”. Rarely, I have no choice but to ignore him. His excitement over the trip, the prospect of riding in Pop’s Ural, and going to the museum with Grandma Cookie stoked his energy & curiosity. 

Nothing bad happened – I just became unavailable (HTTP response code 503). Unable to respond. My mind was elsewhere (typically work) trying to process requests. I had rate-limited my son to try to cope (HTTP response code 413 or 429). A few minutes later I was fine and able to process his requests again.

There are a lot of questions associated with rate-limiting. How much is too much/too little? How can I ensure a good user-experience without sacrificing a potential DDOS attack? When should I introduce rate-limiting into my service?  How can I implement this within my service without putting the resources my service uses at risk? Should I rate limit certain calls over others?

A lot of opensource API-driven services do not include rate-limiting today. You install them, get them configured, then realize there is a security gap that must be resolved before making the service production worthy. 

One solution is openrepose (http://openrepose.org/). Repose stands for REstful PRoxy Service Engine. Yes, it’s a dorky name, but it is a very powerful tool. You can apply rate-limits by HTTP resource, you can query the limits, query as a user where you are with your current limits, and set absolute limits. It’s free, built on standards like WADL and XSD, and running in production at Rackspace (proven). It sits in front of your service and is configured to work with your service. That way you can concentrate on the features you want to provide instead of the rate-limiting that should come with it. 

Also, it also can do a lot more. Authentication filtering, authorization filtering, translation (XML–>JSON), and validation of the incoming call based on WADL. 

I’m begging the Rackers working on this to come up with a version that will work (nicely) with my 4 year old.