Apart form /table
and /schema,
there is also support for the simple endpoints /info
and /rate_limit.
Server Information
The /info
endpoint gives and overview about the available languages on the
server.
sc_info()# A data frame: 2 × 2
locale displayName
<chr> <chr>
1 de Deutsch
2 en English Rate Limits (Table)
The /rate_limit
endpoint shows the number of calls to the /table
endpoint that are remaining.
#> 97 / 100 (Resets at [12:46:54])In this case, we see that 8 out of the 100 requests per hour have
been used up and 92 are still available. The rate limit will be reset
once per hour. In this case this will be at
2022-08-30 13:53:55. The entry under reset should always be
less than one hour after the request to the /rate_limit
endpoint was sent.
Rate Limits (Schema)
Schema requests are currently limited to 10000 requests per hour. The
number of remaining requests can be obtained via
sc_rate_limit_schema(). Rate limits are be returned in the
same format as in sc_rate_limit_table().
#> 9999 / 10000 (Resets at [12:46:54])Rate Limits from headers
All responses from the STATcube API contain rate limit information
(including remaining requests) in the response headers1. So instead of using
the /rate_limit* endpoints shown above, it is also possible
to use responses from other endpoints and extract rate limit information
from their headers.
The function sc_rate_limits() does just that. Any return
value from sc_table(), sc_table_saved() and
sc_table_custom() can be passed to
sc_rate_limits() and the rate limits will be extracted from
the response headers.
sc_example("population_timeseries.json") %>%
sc_table() %>%
sc_rate_limits()#> $schema
#> 9999 / 10000 (Resets at [12:46:54])
#>
#> $table
#> 97 / 100 (Resets at [12:46:54])Note that the function gives rate limits for /schama and
/table even tough only the /table endpoint was
used.
The function also works with return values from
sc_schema() and friends.
#> $schema
#> 10000 / 10000 (Resets at [12:46:54])
#>
#> $table
#> 98 / 100 (Resets at [12:46:54])Server-Side Caching
STATcube uses caching for the /table
endpoint by default. If the same request to sc_table() is
sent several times, this will not count towards the rate-limit (100
requests per hour).
Server-Side caching of /table
responses is currently disabled due to security reasons. Therefore, all
requests against the /table
endpoint count towards the ratelimit.