#1

Hi all, I'm trying to track down an RStudio Connect API endpoint that I have no such luck.

I can't seem to find anything that is related to variants in the API reference (RStudio Connect API Reference).

However, in the rstudio/connectapi github, there is the variant class and is linked to get_variants(), get_default_variant() and get_variant(). And there is a render_variant() that is immensely useful to me, but I don't know how to call it via the API. (see related Programmatically triggering re-rendering of RMarkdown document hosted on RStudioConnect - #2 by cole)

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.

Using the variants endpoint to create new variants
#2

Howdy @jonlin!!

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 :frowning_face: 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:

:speak_no_evil:

  • Take a look at the connect.debug option for connectapi. We should really document this better... it prints the URLs that are requested :wink: And their responses... careful in public forums lest any secrets be leaked! :grinning_face_with_smiling_eyes: :
readRenviron("~/rstudio/connectapi/.Renviron.alt")
options("connect.debug" = TRUE)
client <- connectapi::connect()
#> Defining Connect with server: https://colorado.rstudio.com/rsc
#> https://colorado.rstudio.com/rsc/__api__/server_settings
#> {REDACTED}
invisible(client$me())
#> https://colorado.rstudio.com/rsc/__api__/me
#> {REDACTED}

Created on 2021-07-15 by the reprex package (v0.3.0)

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!!

1 Like
#3

Hey @cole,

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.

This gets me well on my way. Thanks again Cole.

Jon

1 Like
#4

Quick follow-up, @cole. Not sure if its worth creating another post because its the same topic.

I noticed that when I 'render':

render_url <- paste0(rstudioconnecturl, '/__api__/variants/', variant_id, '/render?email=none&activate=true')

payload <- list()
payload <- purrr::list_modify(payload, app_guid = content_id, variant_key = variant_key)

send_render <- POST(render_url,
                    body = payload, encode = "json",
                    add_headers(Authorization = paste("Key", apikey)))

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:

task_id <- content(send_render)$id

task_url <- paste0(rstudioconnecturl, "/__api__/v1/experimental/tasks/", task_id)
task_params <- list(first = 0, wait = 5)

task_result <- GET(task_url,
                   encode = "raw", query = task_params,
                   add_headers(Authorization = paste("Key", apikey)))

content(task_result)$output # this returns an empty list()

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.

Thoughts?

Jon

#5

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 :grinning_face_with_smiling_eyes: )

1 Like
#6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.