pools: Accessing different Crossref API pools

In subugoe/crlite: Lightweight R wrapper for the Crossref REST API

Description

In increasing order of performance: public, polite, plus.

Usage

pools()

req_auth_pool(req, mailto = get_cr_mailto())

resp_cr_pool(resp)

was_pool(resp, pool = pools())

can_pool(pool = pools())

could_pool(pool = pools())

best_pool(mailto = get_cr_mailto())

Arguments

req	A request.
mailto	a character scalar giving a valid email address.
resp	An HTTP response object, as created by req_perform().
pool	giving the name of the expected pool

Related Functions and Methods

Functions

• req_auth_pool: Try to authenticate into the highest performing pool

  Function checks whether a higher performance pool is possible, using could_pool(). Only when that test passes, is the request authenticated. The function thus gracefully recovers from bad mailto and tokens. The function emits intermittent messages about the chosen API pool.

• resp_cr_pool: Show the API pool which served a request

• was_pool: Was the request served by the expected pool? Inspects the response header "x-api-pool" of an existing response to see if it matches the expected pool.

• can_pool: Can requests be served by an expected pool? Performs a request to the API and inspects the response header.

• could_pool: Could the request be served by an expected pool? Checks whether the necessary credentials can be found for higher performance pools.

• best_pool: What is the highest performing pool available? Checks the necessary credentials for the highest performing pool.

See Also

Other api pool access functions: plus, polite

Other api pool access functions: plus, polite

subugoe/crlite documentation built on Sept. 19, 2021, 3:25 a.m.