Would anyone know the URL and/or params needed to call the endpoint?
My use case: I'd like to trigger the 'refreshing' of a RMarkdown document without redeploying it using an API and something like Azure Data Factory, Airflow or Prefect.
Thanks so much for reaching out here, and I'm glad to hear that the connectapi package was useful!
Unfortunately, you are correct - this API is internal and undocumented I am hopeful we will change that in the future, but it is not on our short term roadmap, as far as I am aware.
However, not all hope is lost! There are a couple of ways to follow what connectapi is doing. But before I share, a few caveats:
these functions throw warnings because they are internal APIs. We want users to be aware that they are internal and as such, we are somewhat free to break their behavior without notice between releases
in practice, these APIs are usually quite stable. However, we do recommend testing behavior between Connect releases and moving to a public API once it is available (we are in the process of doing so for the connectapi package, for some other APIs that were somewhat recently made public)
Now, on to the fun stuff! Two options for you:
read the source code for the package... likee.... here:
Take a look at the connect.debug option for connectapi. We should really document this better... it prints the URLs that are requested And their responses... careful in public forums lest any secrets be leaked! :
Feedback on this behavior or things we can improve is welcome, and I will definitely log your request in our tracking system!! Demand for features helps prioritize development, so thank you for sharing this feedback!!
Thanks so much! The connect.debug option is the best way for me to learn how to fish with all the various internal API endpoints, so this is really great. It doesn't include the body though, so I still had to leverage your source code to figure out the last mile.
I've traced what I'm looking for! In short, with a given content_guid (which is the further I can get with the public endpoint), then I can go get its latest variant and key (from the internal API), and then I'll use all that information both the URL and body to render that variant.
I hope the 'render a deployment' or 'render the latest bundle' may comes out as a public API one day. Redeploying has an odd side effect of moving it to the 'top' of the list of RStudio Connect apps (Shiny/RMarkdown/otherwise) every time, so I wanted to minimize that effect.
The send_render will receive an httr object, and the content has an $id in it. Is this a task ID? I only ask because when I send it to the public task API endpoint, my output is empty:
I'm wondering if this is just related to my version of RStudio Connect ( connect_version: 1.7.8-7), or if output logs are not provided when its triggered via the internal variants\render endpoint.
Hey @jonlin ! Interesting! Yeah, I am pretty sure that is a task ID. It's surprising you are getting an empty response though. It might be worth trying something like:
library(connectapi)
con <- connect()
tsk <- Task$new(con, list(task_id="1234"))
poll_task(tsk)
There are some helpers to handle tasks (and I hope I did that right), but they are unfortunately pretty low level. You can see how we handled it in connectapi::variant_render() here:
(Sorry - forgot that you were trying to do the native HTTP - so you were definitely on the right track )