• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Web service
    • None

      We should implement some kind of adaptive rate limiting, so clients do not have to hardcode the 1 request per second rule.

      One way to do this is by using a few HTTP headers to inform a client how many requests they have remaining, e.g.:

      X-RateLimit-Limit: 60
      X-RateLimit-Remaining: 59

      This seems fairly common (see: http://developer.github.com/v3/#rate-limiting , https://dev.twitter.com/docs/rate-limiting/1.1 , https://www.discogs.com/developers/accessing.html , etc..), and most of these APIs use some kind of limit/remaining scheme. But there are probably alternative ways to communicate a rate limit to a client through HTTP headers, we should probably look at some alternatives as well.

      Being able to dynamically tweak these values could help us deal with temporary heavy loads (e.g. enforce a temporary decrease in request rates when one or more servers are out of rotation, etc..).

      We should implement these headers ASAP, even if they'd be largely dummy values at first. Because clients are slow to update their software and get the updated versions in the hands of users, we should encourage them to implement using these headers now so we can benefit from it when we do a proper implementation of them in the server later on.

          Loading...

            • Icon: Improvement Improvement
            • Resolution: Unresolved
            • Icon: Normal Normal
            • None
            • None
            • Web service
            • None

              We should implement some kind of adaptive rate limiting, so clients do not have to hardcode the 1 request per second rule.

              One way to do this is by using a few HTTP headers to inform a client how many requests they have remaining, e.g.:

              X-RateLimit-Limit: 60
              X-RateLimit-Remaining: 59

              This seems fairly common (see: http://developer.github.com/v3/#rate-limiting , https://dev.twitter.com/docs/rate-limiting/1.1 , https://www.discogs.com/developers/accessing.html , etc..), and most of these APIs use some kind of limit/remaining scheme. But there are probably alternative ways to communicate a rate limit to a client through HTTP headers, we should probably look at some alternatives as well.

              Being able to dynamically tweak these values could help us deal with temporary heavy loads (e.g. enforce a temporary decrease in request rates when one or more servers are out of rotation, etc..).

              We should implement these headers ASAP, even if they'd be largely dummy values at first. Because clients are slow to update their software and get the updated versions in the hands of users, we should encourage them to implement using these headers now so we can benefit from it when we do a proper implementation of them in the server later on.

                    Unassigned Unassigned
                    warp Kuno Woudt
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                      Created:
                      Updated:

                        Version Package

                          Unassigned Unassigned
                          warp Kuno Woudt
                          Votes:
                          0 Vote for this issue
                          Watchers:
                          0 Start watching this issue

                            Created:
                            Updated:

                              Version Package