-
Notifications
You must be signed in to change notification settings - Fork 0
Rate limiting your API. How do we do it well?
Session Leader: Bryan Barnard (@nardbard)
Overview
Talk about providing rate limiting functionality as part of your API. Goal of this talk was to discuss how people are implementing rate limiting and or quotas for their APIs and identify good practices for rate limiting from both a API consumers view and and API providers view. An immediate finding was that all parties believed that it was a good practice to have the ability to rate limit your API and build this in from the start to provide API providers with a mechanism to defend their APIs from intentional or unintentional high request volumes that could lead to infrastructure issues or possible DOS.
What are we limiting?
- Requests
- Data
Goals / Why
- defend your api and infrastructure
- upsell / charge for access
- Finding: Should have some form of rate limiting to have option to protect service and prevent outage.
Communication to Client
-
Terms of service
-
Dev portal providing:
- documentation
- usage metrics and analytics
- status of rate quota use
- Notifications (email, push)
-
Status Codes & Headers
- Headers to show current usage, is there a common header
- 429 is standard status code
- Potential need for new standardization of headers to provide reasoning info to clients (RFC Proposal?)
- Machine Readable
- Messaging on quota window time
Downtime/Punish
- If charging (quota) provide messaging and begin upcharging for usage over quota
- if defending:
- provide warnings
- notify
- tar pit requests (artificial latency) / back pressure
- if caching implemented send cache control headers to encourage more time between requests
Quota Vs. Limit
- If defending then this is an access limit / rate limit
- if charging for access then this is a quota
Measure
- Requests / time period (i.e., second, hour, etc…)
- Amount of data (i.e., payload size)
- Per client
- Per app, per user
Cloud providers are now providing rate limiting
- Amazon
- MSFT
Many API-Gatway Vendors Providing rate limiting
- Akana
- Apigee
- Mulesoft
Identify Requester
- Token (OAuth)
- API Key
- Crypto (Secure) User Agent for method of Announce Identity so that provider will trust but verify identity
Build Vs. Buy
- Many vendors and cloud providers now providing rate limiting as a service
- Good learning experience
- Open source projects exist that help with implementation