rOpenSci | Why You Should (or Shouldn't) Build an API Client

Blog
1

These days web Application Programming Interfaces (APIs) are everywhere (scientific data sources, your system for Customer relationship management, cat facts API…). Do you need to write some R code wrapping a web resource such as an API? Packaging it up might be useful to you or your team for the same reason as any code. Now, whether you really want to publicize the package and to guarantee its maintenance might be slightly trickier than for other packages, as the usefulness and status of your package will depend on the web API being up and running according to expectations. This creates a surface for failures that might be more or less scary depending on your trust in the upstream maintainers.

This is a companion discussion topic for the original entry at https://ropensci.org/blog/2022/06/16/publicize-api-client-yes-no/
3

To combine this with Maëlle’s Evaluating GitHub Activity for Contributors, there is an R package to dynamically generate a client from a Swagger definition, but it’s for Swagger 2, not Swagger 3/OpenAPI and the project seems inactive. It threw a warning but did work for the OpenAPI definition I tried for an API where I’m ironically a contributor to the R package (see How to substitute for fields in an endpoint path? · Issue #17 · bergant/rapiclient · GitHub)

The dynamic client would obviously keep up with the API provider’s Swagger changes, but your code calling the dynamic client would most likely break when the API changes :frowning:

1 Like