Open jameslamb opened 4 years ago
Thanks for posting, @jameslamb ! I love this idea of taking the time to shore up bits and pieces of many different packages and spreading best practices.
Another good outcome might be seeing if RStudio would take a PR to {httr}
's 'Best Practices for API packages' vignette to share this advice more broadly
My workflowr package is one of those reverse dependencies, and I super welcome a PR to make the GitHub API calls more robust.
The function create_gh_repo()
makes 3 GET
requests and a POST
request.
I wrote up a 101-level "wtf is HTTP" last night: https://github.com/jameslamb/talks/tree/master/chi-r-collab-httr. Decided to put it in that repo because I might turn it into a lightning talk in the future.
For those who want to do the "go make PRs to existing packages" part of this project, here are some examples:
The basic process is:
Reverse Depends
and Reverse Imports
. Choose one that sounds interesting and click on it.URL:
section with a GitHub link. Click it.fork
to fork it. (GitHub docs)httr
single-shot functions.
DELETE()
GET()
HEAD()
POST()
PATCH()
PUT()
VERB()
git grep 'POST('
or using Find in Files in RStudiohttr::RETRY()
. See the pull requests linked above for some examples.Some resources shared during our first chat:
TL;DR
There are a ton HTTP clients on CRAN, and many of them make single pass-or-fail HTTP requests. If they added some retry logic (with
httr::RETRY()
), they would be more resilient to transient issues like brief network disruptions or service downtime.Details
{httr}
is a super-popular package for making HTTP requests in R and handling their response. It has a LOT of direct reverse imports, and impacts a lot of other projects indirectly.I have seen many examples of packages where people use functions like
httr::GET()
,httr::POST()
,httr::VERB()
, etc. to make HTTP requests. These functions attempt to make a single request and raise an error if anything goes wrong.I believe (though I don't know for sure) that this all-or-nothing approach is not something package authors have carefully and intentionally chosen, and changing those calls to
httr::RETRY()
would make those packages more resilient to transient problems like brief network outages or periods where the service(s) it hits are overwhelmed. In my experience, using retry logic can improve the user experience with HTTP clients.I propose a group spend some time improving the ecosystem of HTTP clients in R by repeating these steps:
{httr}
reverse importshttr::GET()
,httr::POST()
,httr::PUT()
,httr::VERB()
,httr::DELETE()
,httr::HEAD()
, andhttr::PATCH()
and replace them with the appropriatehttr::RETRY()
I'd be happy to start out with a short introduction to HTTP and what
httr::RETRY()
actually does.