Functions to manipulate shared links about boxr HOT 1 OPEN

Absolutely! Would love to get some more API endpoints wrapped with R code.

My thoughts to your bullets:

Should there be separate user-level functions for add, update and removing shared links, or attempt to consolidate?

I think there are probably at least 7 functions.
3 internal: GET _shared_link, GET _shared_link/file_id, PUT _shared_link/file_id
4 external: find_folder, get_link, add_link, delete_link

Whether to ignore bad param combinations as i currently do or throw errors

I think boxr should faithfully return the APIs response here. If there is an error throw it, if not carry on.

Including the unshared at and vanity name request options

We should be exposing as much of the API as possible for users to manipulate. I think these should be included

What should be an internal vs external function in boxr

Externals are nice human readables that collect arguments for the Internals, like get tokens and paths, maybe decorate with classes.
Internals are the cURL commands, doing the RETRY logic, the GET / PUT path the API wants.

I haven't done anything to wrap the httr result into a boxr object, so need to figure out which ones are available/whether we need a new one

Lets save this for last

Is there anything more opinionated that we could do? Some vague ideas include combining the file and folder endpoints, or adding auto share to some of the upload functions.

Combining endpoints might be less verbose if the two APIs are identical. But the API separated for them for a reason, keeping them separated for our wrappers is safer in case things change in the future.

Naming, as always!

Save this for last, last!

Does any of that not make sense?
I think starting with the code you have and adding some unit test cases for this would be the best place to start a PR.

from boxr.