Move Rate Limiting to be an object off Consumer instead off a Plugin

[scottefein]

I recently started looking the Rate Limiting Plugin and a few things about it bugged me...

Unlike Consumers, Rate Limits cannot be pulled out as definitive objects. If you want to find a rate limit, you need to do this:

"/apis/#{api}/plugins?name=rate-limiting&consumer_id=#{consumer_id}"

Because you're filtering, instead of getting a 404 when it's empty, you get an empty Data:[]. Now that's proper for when you're filtering for a list. However that's a weird experience when you're checking to see if a rate-limit has been created yet.

My understanding : Rate Limits Belong to consumers and APIs, and Consumers can only have one rate-limit per API.

Proposed Rate Limits Format:

"/consumers/#{consumer_id}/rate-limits/#{api name, id, or rate-limit ID}" (returning a single rate limit object, as you have a 1:1 relationship here) "/consumers/#{consumer_id}/rate-limits" (returning all rate-limits enabled for that consumer) "/apis/#{api}/rate-limits?consumer_id=#{consumer_id}&key=#{key}" (returning the Data[""], as you're actually filtering here to see if a consumer and/or their key's rate limit)

[thibaultcha]

That does make sense to me. This would be relatively simple to implement, one just needs to extend the Admin API with an api.lua file in the rate-limiting plugin, and implement those routes there. I will take a stab at it if I have some spare time...

[scottefein]

Mind if I take a stab at it first? I'll ping you on Slack if I run into issues... On Dec 17, 2015 8:54 PM, "Thibault Charbonnier" notifications@github.com wrote:

That does make sense to me. This would be relatively simple to implement, one just needs to extend the Admin API with an api.lua file in the rate-limiting plugin, and implement those routes there. I will take a stab at it if I have some spare time...

— Reply to this email directly or view it on GitHub https://github.com/Mashape/kong/issues/792#issuecomment-165636736.

[thibaultcha]

Sure! Just a few things then:

• base your feature branch on next, and when ready you can propose a PR back to next.
• take a look at the crud_helpers file to see how the DAO is used (the crud methods might be too generic for this)
• this should probably consider #737, and be implemented in a slightly better way ^^

[BrianHutchison]

+1 Very interested in this. Any progress report?

[rsoletob]

+1