Przykłady nagłówków odpowiedzi HTTP ograniczających szybkość interfejsu HTTP

82

Jeden z dodatkowych kodów stanu HTTP ( RFC6585 ) to

Gdzie mogę znaleźć przykłady nagłówków odpowiedzi HTTP z ograniczeniem szybkości przesyłania danych przez interfejs API HTTP / REST, które są przydatne w przypadku tego stanu odpowiedzi HTTP?

M8R-1jmw5r
źródło
Ponadto sposób korzystania z tych nagłówków jest inny. response.headers["x-ratelimit-limit"]
Manish

Odpowiedzi:

127

Oto kilka przykładów nagłówków odpowiedzi HTTP ograniczających prędkość interfejsu API. Zaczerpnięte z czterech popularnych interfejsów API REST: Github, Vimeo, Twitter i Imgur:

Github Rate Limiting http://developer.github.com/v3/#rate-limiting

#=============================#=============================================#
# HTTP Header                 # Description                                 #
#=============================#=============================================#
| X-RateLimit-Limit           | Request limit per hour                      |
+-----------------------------+---------------------------------------------+
| X-RateLimit-Remaining       | The number of requests left for the time    |
|                             | window                                      |
+-----------------------------+---------------------------------------------+

Vimeo Rate Limiting http://developer.vimeo.com/guidelines/rate-limiting

#=============================#=============================================#
# HTTP Header                 # Description                                 #
#=============================#=============================================#
| X-RateLimit-Limit           | Request limit per day / per 5 minutes       |
+-----------------------------+---------------------------------------------+
| X-RateLimit-Remaining       | The number of requests left for the time    |
|                             | window                                      |
+-----------------------------+---------------------------------------------+
| X-RateLimit-Reset           | The remaining window before the rate limit  |
|                             | resets in UTC epoch seconds                 |
+-----------------------------+---------------------------------------------+

Ograniczanie szybkości interfejsu API REST na Twitterze https://dev.twitter.com/docs/rate-limiting/1.1

Uwaga: Twitter używa nagłówków o podobnych nazwach, takich jak Vimeo, ale ma inny myślnik w każdej nazwie.

#=============================#=============================================#
# HTTP Header                 # Description                                 #
#=============================#=============================================#
| X-Rate-Limit-Limit          | The rate limit ceiling for that given       |
|                             | request                                     |
+-----------------------------+---------------------------------------------+
| X-Rate-Limit-Remaining      | The number of requests left for the         |
|                             | 15 minute window                            |
+-----------------------------+---------------------------------------------+
| X-Rate-Limit-Reset          | The remaining window before the rate limit  |
|                             | resets in UTC epoch seconds                 |
+-----------------------------+---------------------------------------------+

Limity szybkości interfejsu Imgur API http://api.imgur.com/

#=============================#=============================================#
# HTTP Header                 # Description                                 #
#=============================#=============================================#
| X-RateLimit-UserLimit       | Total credits that can be allocated         |
+-----------------------------+---------------------------------------------+
| X-RateLimit-UserRemaining   | Total credits available                     |
+-----------------------------+---------------------------------------------+
| X-RateLimit-UserReset       | Timestamp (unix epoch) for when the credits |
|                             | will be reset                               |
+-----------------------------+---------------------------------------------+
| X-RateLimit-ClientLimit     | Total credits that can be allocated for the |
|                             | application in a day                        |
+-----------------------------+---------------------------------------------+
| X-RateLimit-ClientRemaining | Total credits remaining for the application |
|                             | in a day                                    |
+-----------------------------+---------------------------------------------+
M8R-1jmw5r
źródło
12
Jeśli projektujesz własne nagłówki limitów szybkości, odpowiednim zasobem jest Best Current Practice BCP178, w którym zaleca się wycofanie prefiksu X-. Więcej informacji znajdziesz w oryginalnym RFC / BCP. tools.ietf.org/html/bcp178
10gistic,
Świetne przykłady, stworzyłem pakiet Node.js, który może być używany z requestpakietem: github.com/webjay/x-rate
webjay
32

Oprócz nagłówków specyficznych dla API, nie zapomnij o skromnym, standardowym Retry-Afternagłówku

Serwery wysyłają pole nagłówka „Ponów próbę po”, aby wskazać, jak długo klient użytkownika powinien czekać przed wysłaniem kolejnego żądania ... Wartość tego pola może być datą HTTP lub liczbą sekund opóźnienia po otrzymaniu odpowiedzi.

Norma zawiera szczegółowe zalecenia dodatkowe w przypadku używania go z kodem stanu 503 lub 3xx:

W przypadku wysłania z odpowiedzią 503 (Usługa niedostępna) Ponów próbę po wskazuje, jak długo usługa ma być niedostępna dla klienta. W przypadku wysłania z jakąkolwiek odpowiedzią 3xx (przekierowanie) Retry-After wskazuje minimalny czas oczekiwania przez agenta użytkownika przed wysłaniem przekierowanego żądania.

Raedwald
źródło
2
Retry-Afterjest przeznaczony do użycia z 503lub 30xresponses tools.ietf.org/html/rfc7231#section-7.1.3
Russbear
3
@Russbear, ale nic w tej sekcji nie wskazuje, że nie można go używać z innymi kodami odpowiedzi.
Raedwald
20
429 Zbyt wiele żądań: „Reprezentacje odpowiedzi POWINNY zawierać szczegóły wyjaśniające warunek i MOGĄ zawierać nagłówek Retry-After wskazujący, jak długo należy czekać przed wysłaniem nowego żądania.” tools.ietf.org/html/rfc6585#section-4
MRA