README.md in platform-api-2.2.0 vs README.md in platform-api-2.3.0.pre.1

- old
+ new

@@ -49,11 +49,11 @@ For example, to get information about the `web` formation on the `sushi` app you'd invoke `heroku.formation.info('sushi', 'web')` and it would return a Ruby object that matches the one given in the [response example](https://devcenter.heroku.com/articles/platform-api-reference#formation-info). -The [API documentation](http://heroku.github.io/platform-api/_index.html) contains a +The [API documentation](http://heroku.github.io/platform-api/_index.html) contains a description of all available resources and methods. ### Handling errors The client uses [Excon](https://github.com/excon/excon) under the hood and @@ -306,10 +306,47 @@ ```ruby client = PlatformAPI.connect('my-api-key', url: 'https://api.example.com') ``` +### Rate throttling + +Rate throttling capability is inclued in PlatformAPI v2.3.0, but is disabled by default. The following section describes the behavior of the PlatformAPI gem v3.0.0+. To enable rate throttling logic, upgrade to the latest released version. + +By default client requests from this library will respect Heroku's rate-limiting. The client can make as many requests as possible until Heroku's server says that it has gone over. Once a request has been rate-limited the client will sleep and then retry the request again. This process will repeat until the request is successful. + +Once a single request has been rate-limited, the client will auto-tune a sleep value so that future requests are less likely to be rate-limited by the server. + +Rate throttle strategies are provided by [the Rate Throttle Client gem](https://github.com/zombocom/rate_throttle_client). By default the `RateThrottleClient::ExponentialIncreaseProportionalRemainingDecrease` strategy is used. + +To disable this retry-and-sleep behavior you can change the rate throttling strategy to any object that responds to `call` and yields to a block: + +```ruby +PlatformAPI.rate_throttle = ->(&block) { block.call } + +# or + +PlatformAPI.rate_throttle = RateThrottleClient::Null.new +``` + +By default rate throttling will log to STDOUT when the sleep/retry behavior is triggered: + +``` +RateThrottleClient: sleep_for=0.8 +``` + +To add your own custom logging, for example to Librato or Honeycomb, you can configure logging by providing an object that responds to `call` and takes one argument: + +```ruby +PlatformAPI.rate_throttle.log = ->(info) { + # Your logic here + + puts info.sleep_for + puts info.request +} +``` + ## Building and releasing ### Generate a new client Generate a new client from the Heroku Platform API JSON schema: @@ -343,11 +380,11 @@ And then visit `doc/index.html` to read it. Alternately, build and publish it to Github Pages in one step with: ``` -rake publish +rake publish_docs ``` You can see it live on [Github Pages](http://heroku.github.io/platform-api/). ## Contributing @@ -355,5 +392,25 @@ 1. [Fork the repository](https://github.com/heroku/platform-api/fork). 2. Create your feature branch: `git checkout -b my-new-feature` 3. Commit your changes: `git commit -am 'Add some feature'` 4. Push to the branch: `git push origin my-new-feature` 5. Create new pull request. + +## Testing + +The tests make live network calls so you'll need to ensure that you're logged into your Heroku account. You'll also need an application that uses a set of Heroku's features, if you don't have one you can create one. E.g. + +``` +$ git clone https://github.com/heroku/ruby-getting-started.git +$ cd ruby-getting-started/ +$ heroku create <memorable-name-here> +$ heroku webhooks:add -i api:dyno -l notify -u https://example.com/hooks +$ git push heroku master +``` + +Now you can specify your app name while you run tests: + +``` +$ TEST_APP_NAME="<memorable-name-here>" rspec ./spec +``` + +If you run tests without specifying a `TEST_APP_NAME` then an app will be created and deployed under your user account.