@chriddyp @cldougl @etpinard @BRONSOLO thoughts?

I think a super-thin wrapper around our underlying api might be pretty nice!

It would nicely solve the following within the same framework:

"From the api..."

• "how do i delete my plots?"
• "how can i lookup a plot by it's filename"
• "how can i change the privacy of a plot"
• "how can i get a list of my plots"
• "how can i move a file into a folder"

This would be totally orthogonal to the idea of Figure and Grid creation. These objects would be wrappers that make it easier to handle the more general files.

The other option is to somehow build all of this into Figure and Grid objects. But I'm starting to thing that we'd be straying too far from the actual implementation? I don't think the abstraction is all that helpful?

I'd love any thoughts on this one. There are a few issues in this repo that I think this would solve cleanly.

Also, this is a general api-wrapper question. It'd be nice to have some sort of uniform way to do things like this across our wrappers, yeah?

👍

I think @doeg had some thoughts on this too (from the node perspective)

Cool! Yeah, (re?)writing the Plotly API as an npm module is ticketed here: https://github.com/plotly/streambed/issues/3013

We haven't been thinking about it yet, but I'm definitely interested in this discussion. The thinner and more closely coupled the wrapper is to our actual API the better, in my opinion.

If anyone has any examples of some especially well implemented APIs, I'd love to see 'em. (I know Twitter's entire API is an antipattern of what not to do...)

part of me feels like we should just document how to do this well with requests. Read through their quick-start, as he explores the github api: http://docs.python-requests.org/en/v1.0.1/user/quickstart/

maybe the best approach is to document how to do these common tasks (with requests), and then see if there is any annoying boiler plate code that we can simplify for people.

the nice thing about keeping it tightly coupled to the API is that we'll only need to update the api.plot.ly docs

@doeg yeah the npm module spec you've got going is right inline with what I want for the Python API.

@chriddyp totally see your point about not maintaining another hunk of code. just thought I'd bring this up though. as our api gets more consistent, implementing a thin wrapper around it gets easier. that said, it's still something to maintain.

Hey! I ended up finally doing this in #640. It ended up really helping to unify our response handling! Closing this in favor of the changes in #640. It's basically a super thin wrapper around requests.request for all our api endpoints.