jonthegeek / asanar Goto Github PK

I need to either export the response objects from the API, or provide them somewhere for functions that have the opt_fields argument. Right now I have to check the API to see what to put in there, and that's no good!

I'm trying to figure out how (if) I can figure out what "extra" fields are available for things that return the "Compact" version of a response. If I can find that, it'd be nice to provide suggestions in opt_fields (ideally in an autocomplete-friendly manner). It SHOULD act like an enum column, but I'm not sure it's actually available in the spec, so this might not work for the auto version.

The "events" endpoint returns an object with "data", "sync", and "has_more". Those last two pieces are vital to getting the full result, but currently we don't return them; we just pull out data.

Implement pagination, custom response handlers, etc. This really needs a refresh with the latest version of nectar!

Re-scrape the API and produce the package, using what I have learned from other APIs. Start moving toward the final beekeeper thing.

Specific things to sort out:

• Codify the idea I started to implement in youtubeR, where api_spec$components$schemas (and probably other things) get parsed into ~validation functions. Don't try to recombine things; use the power of R to automatically do that. Part of the result here will be that we can write cleaning functions for each schema or type of schema or something along those lines, and integrate "rectangle the returns" at the ~core of the package (in a way that auto-extends to all of the paths).
• Clean up the way error messages are handled.
• Better handling of optional args.
• Automatically convert R-style inputs to required shapes (shouldn't need .to_csv-style functions in wrapper package(s)).

opt_fields says it accepts a "list", but that's really a character vector, which then needs to be merged via paste(..., sep = ",") (or collapse depending how it comes in).

Identify a rule for this. It feels likely that all things that are "arrays" in query params should be sent in as a character vector and then concatenated.

If you try to use asanar without an API token, the error is generic. Catch that earlier.

/events ("Get events on a resource") returns a 412 the first time you call it for a resource, providing a "sync" token. We need to treat that as a response, not an error, and then make the request again with that sync token. Check the spec to see if anything else does something simlar.

Add a function to do the interactive oath2 dance.

I'm PRETTY sure the final output should just be a token set to the default env variable (and instructions for how to use it), but we'll see if that changes as I implement a standard httr2 flow.

Make sure the result will be compatible with a shinyslack-style flow.

Implement the Batch API.

Implement rate limiting in the basic requester.

Rate limits depend on whether the "domain" is premium or free. That means both the user and the workspace are premium, I believe. So far the best option I can find is to hit a premium-only endpoint like /workspaces/{workspace_gid}/tasks/search and save a variable about whether the user can hit that or not.

I'm still trying to find a quick & easy check.

Be sure to also deal with the error version (retry after a wait).

The OpenAPI spec for this API is available here.

I tried generating a first version of the package using the OpenAPI Generator, but I didn't like the result.

Instead, for this issue, set up a framework to quickly generate boilerplate code for a function, but don't automatically do it all at once. It makes too much noise to deal with (and repeatedly does things I don't like).

If a required argument is missing, we throw a cryptic vctrs_vec_compat error. Let's make that make more sense

testing <- asanar:::asn_get_attachments_for_object()

I don't want to default params to NULL, but that means I need to properly ignore optional params that aren't passed in. I mean, or default to NULL.

I'm also not currently dealing with required vs not required, I think I need to implement that at the same time.

The inputs have explicit properties, including class and (when appropriate) possible enum values. Build functions to check them, both ~generically (character checker, etc) and specific ("this one can have these values").

Each function has its own expectations about the returned result. As much as possible, auto-build rectanglers/parsers, but also leave room for that in the function definitions.

Note that we'll almost definitely want to be bi-directional about this; there might be cases where the ~raw return object is potentially the input for the next function (confirm that's true before writing the ticket to go back the other way, though; if it is, we probably want S3 methods for the arg-checkers, to go backwards when they get a data.frame or maybe a specific type of data.frame).

Tasks can have custom fields. The way that data is returned by the API is super messy. Clean it up.

This ticket requires deciding where the line is between {asanar} and a higher-level package, and how that structure will be supported by beekeeper.

Give the return a class, so it's easier to differentiate a list of returns from a single list-like return.

Add a vignette explaining how to set up auth. Or maybe just put this in the asn_browse_token() documentation?

Write a function that does the actual request, given all the endpoint info.

This function probably won't be exported long-term; it's the function all the other functions will call. And it doesn't need strict checks on parameters (other than possibly some centralization), because the functions that call it will deal with that.

We DO need to support all of the HTTP methods (well, GET, DELETE, POST, and PUT).

This iteration doesn't need to understand the batch api nor rate limits, but those will come soon.

Parse the API spec for the 7 /users` endpoints:

• /users
• /users/{user_gid}
• /users/{user_gid}/workspace_memberships
• /users/{user_gid}/user_task_list
• /users/{user_gid}/team_memberships
• /users/{user_gid}/teams
• /users/{user_gid}/favorites