Rate-limiting, REST Hooks, and the API

Thoughts

In a bit of a change of mind, I’ve decided now that an API is an abuse control measure, not an abuse-enabling method.  This bodes well for delivery of the API with the first release of the re-written TightURL.

REST Hooks (and how they enhance site reliability and performance)

I came to this conclusion during consideration of REST Hooks, an implementation of a method for pushing data via REST instead of polling.  I will be implementing something along the lines of REST Hooks in the TightURL API.  Concurrently, the TightURL UI will become rate-limited, forcing automated bulk additions to go through the API.  In turn, at least certain parts of the API will require an API key.  The use of an API key allows TightURL site operators much better control over how users use the service.

The primary motivation of REST Hooks is to eliminate the vast waste associated with polling.  If you eliminate the necessity of making all those polling calls, you can drastically reduce the number of calls any given API key is allowed to make.

Rate Limiting

The rate limiting in TightURL will (likely) revolve around four totals:

  1. Usage of the User Interface (web page)
  2. API calls to add a URI
  3. API calls to lookup a TightURL ID
  4. API calls for everything other than items 2 and 3.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *