This is a feature request, which I will explain below. If you want, I can prepare a PR with the suggested change. But I first wanted to get the package developer's opinion on this before putting any effort into this.
Why?
I have several packages that wrap certain APIs, where the result is returned as a data.frame to the user. The API allows operations that are very similar to those provided by the tidyverse, like filter(), select(), arrange() and slice_head(). Which would require a special instance of the request class.
How
In my case, I have created a special request class object (which inherits from the httr2::request class) for those APIs. It allows the user to apply the tidyverse operators to that special request, before it is submitted to the server.
This works by lazily adding the operations as named elements to the object. They need to be parsed to a format that the API understands before the request is performed. As each API might need different parsing, this cannot be handled by single generic. See for instance this API parser
At the moment I have written a custom req_perform(req, …) function which masks the one from httr2. When req is an ordinary request, it will just call httr2::req_perform(). Otherwise, it will first parse the API request, and then call httr2::req_perform().
Feature request
Although the approach described above works, it is not that elegant. If httr2::req_perform() was an S3 generic, I could write a specific implementation for that generic for a specific API. This way we could extend httr2, just like how dbplyr extends dplyr, focusing on database connections.
Please let me know if this suggestion makes any sense, or whether I need to provide more details. Also let me know, if you want me to prepare a PR to implement this feature.
Related issues
#522
This is a feature request, which I will explain below. If you want, I can prepare a PR with the suggested change. But I first wanted to get the package developer's opinion on this before putting any effort into this.
Why?
I have several packages that wrap certain APIs, where the result is returned as a
data.frameto the user. The API allows operations that are very similar to those provided by the tidyverse, likefilter(),select(),arrange()andslice_head(). Which would require a special instance of therequestclass.How
In my case, I have created a special
requestclass object (which inherits from thehttr2::requestclass) for those APIs. It allows the user to apply the tidyverse operators to that special request, before it is submitted to the server.This works by lazily adding the operations as named elements to the object. They need to be parsed to a format that the API understands before the request is performed. As each API might need different parsing, this cannot be handled by single generic. See for instance this API parser
At the moment I have written a custom
req_perform(req, …)function which masks the one from httr2. Whenreqis an ordinary request, it will just callhttr2::req_perform(). Otherwise, it will first parse the API request, and then callhttr2::req_perform().Feature request
Although the approach described above works, it is not that elegant. If
httr2::req_perform()was an S3 generic, I could write a specific implementation for that generic for a specific API. This way we could extend httr2, just like howdbplyrextendsdplyr, focusing on database connections.Please let me know if this suggestion makes any sense, or whether I need to provide more details. Also let me know, if you want me to prepare a PR to implement this feature.
Related issues
#522