crlite

TL,DR: You should probably be using the rcrossref client instead.

The goal of crlite is to make it easier to use the Crossref REST API from R in production. To that end, it differs from the existing (and much more mature and comprehensive) rcrossref in several ways:

1. crlite is a minimalistic wrapper in the spirit of gh: It handles the API requests (authentication etc.) but otherwise leaves users to write their own queries. In production use, this may make the package more stable because it cuts a layer of complexity and allows more tightly focused queries and smaller data structures. In interactive use, this can cause more work. crlite also aims to be more stable, and require less maintenance, because it does not replicate the crossref API. Callers will be responsible for adapting their code to changes in the API.

2. crlite provides some type- and length-stable field accessors. The crossref API itself is (? https://github.com/subugoe/crlite/issues/20) not type- and length-stable. This instability is (unavoidably) imported into the rcrossref client, as it wrangles unstable API results into useful R objects. For example, in rcrossref::cr_works(), the order and number of columns may differ, depending on whether some field is included in the JSON returned from the corresponding /works endpoint. This is not the fault of rcrossref, but a necessary result of wrapping an unstable API in R dataframes (unless you want to reimplement the entire API spec in R to reassert stability). In interactive use, the instability may be a minor concern, outweighted by the convenience of ready-made R objects. In production use, type- and length-instability can cause unexpected, hard to debug errors or requires non-idiomatic workarounds.

   By accessing only single fields, crlite can safely assert the type and content of the returned JSON, and return a type- and length-stable NA otherwise. These accessors, will, however remain tightly limited.

3. crlite caches all requests transparently. In production, this allows for greater separation of concerns. Instead of worrying about efficient API usage, production code can call crlite depending on what makes idiomatic sense.

4. crlite uses httr2, not crul under the hood.

5. crlite provides extensive support for the higher-performance polite and plus API pools.