Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropbox API v2 launches

blogs.dropbox.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Dropbox API v2 launches

#61

Post by MichaelGG »

dragonwriter wrote: post #31
BinaryIdiot wrote: post #28

Earlier quoted context omitted.

You are apparently me. I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're…

> Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. (You probably would want to have authoritative URLs for the subresour…

Really? I thought REST says you shouldn't assume URLs follow any pattern. So if you want to get product 123, you need to search for it, then find the URL. Instead of doing Concat("/product/", prodId).

Twilio is an interesting case. They claim all REST, yet they encourage people to generate URLs using IDs. (Twilio's API is great, apart from the incomphrensible decision to use IETF style dates, the silly "Mon, Nov 8 2009" format that only made sense in the 70s over obvious year-month-etc. style.)

I'm not sure there are any popular, really REST APIs out there.

Re: Dropbox API v2 launches

#64

Post by smarx »

dsp1234 wrote: post #50
denniskane wrote: post #38

Earlier quoted context omitted.

Well, if JavaScript were meant to be used as an actual programming language, then it would make sense to develop an SDK for it. I'm only half joking there :) In all seriousness, though, it did make my brain tilt about 15 degrees to see the words "JavaScript" and "SDK" next to each other like that.

In all seriousness, though, it did make my brain tilt about 15 degrees to see the words "JavaScript" and "SDK" next to each other like that. AWS has two JavaScript SDKs. https://aws.amazon.com/sdk-for-browser/ https://aws.amazon.com/sdk-for-node-js/

And Dropbox has one for API v1: https://github.com/dropbox/dropbox-js. There will be one for v2 as well.

Re: Dropbox API v2 launches

#65

Post by ericingram »

BinaryIdiot wrote: post #28
swax wrote: post #12

Earlier quoted context omitted.

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel i…

You are apparently me. I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're…

I think we solved the common issues with REST for Schema (https://schema.io) in a way that makes it really nice for developing web apps. For example, to include related resources you can specify an `expand` field in a get request, and if you want to include unrelated resources you can do it with the `include` field.

There are probably good ways to solve most if not all of the problems people typically run into with REST APIs for web apps, but it could take a lot of experimentation to figure them out. It sure took us a while.

Re: Dropbox API v2 launches

#66

Post by dragonwriter »

MichaelGG wrote: post #61
dragonwriter wrote: post #31

Earlier quoted context omitted.

> Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources. (You probably would want to have authoritative URLs for the subresour…

Really? I thought REST says you shouldn't assume URLs follow any pattern. So if you want to get product 123, you need to search for it, then find the URL. Instead of doing Concat("/product/", prodId). Twilio is an interesting case. They claim all REST, yet they encourage people to generate URLs using IDs. (Twilio's API is great, apart from the incomphrensible decision to use IETF style dates, the silly "Mon, Nov 8 20…

> Really? I thought REST says you shouldn't assume URLs follow any pattern.

It does, but that's an unrelated issue to the one addressed in GP, which addresses the condition where the information exists on the server side when the response is sent to know what subresources are part of the composite that is desired.

> I'm not sure there are any popular, really REST APIs out there.

The Web itself is a popular API, which provided both the motivation for defining REST and which was, itself, shaped by REST in that REST was developed in parallel with and influenced the design of HTTP/1.1.

Re: Dropbox API v2 launches

#67

Post by DenisM »

So is this the API for clients or for servers?

I would like my web server to be able to slurp up all the images from my customer's Dropbox. Unfortunately, shared folders can't be downloaded if they are larger than 2Gb, which is quite often for me.

Is there an API suitable for this?

EDIT: oh yes, yes there is! https://www.dropbox.com/developers/chooser

EDIT 2: It would be sweet if you guys also exposed SHA2 hash of the files in Choser. Often times they user will mistakenly load the same file, and I would rather not do the work at all if I don't have to.

Re: Dropbox API v2 launches

#68

Post by cunac »

ajkjk wrote: post #53
cunac wrote: post #33

Earlier quoted context omitted.

in this case there is no reason to do that and you lose all possibilities of using cache if that is desirable GET /users/@me/accounts/:id --> specific user account GET /users/@me/accounts --> all user accounts would suffice and would read naturally , it would also give you ability for other user with appropriate credentials (admin kind) to see some other user account information yes, very disappointed with design dec…

My point is that in complex systems 'get' use cases come up that don't fit well in urls. Suppose you have too many accounts to list, so you start taking predicates in the API, or you start returning a pagination token that's passed back in on a subsequent requests. You quickly overwhelm URIs and have to start serializing complex objects in headers or query params. Eventually you give up and switch to POST so you can…

I do build a complex systems and pagination payload always have links to prev/next etc. , POST for GET would kill all client side and server side caching we leverage and would make system really hard to scale. We still didn't run into compelling case to use POST for this type of fixed queries.

What you are talking is ad hoc search capability and that is usually done differently either by posting content type which indicates search payload or using different generic URI for search queries within a whole system

Re: Dropbox API v2 launches

#69

Post by awakeasleep »

smarx wrote: post #46
awakeasleep wrote: post #43

No love after begging for an administration API for 2+ years. At this point they should start putting some spin on it. "Help your company employ more people. Dropbox for Business's lack of administration tools will grow your headcount. When you see your admins waiting for a list of users to load, or trying to write their own tools based on scraping the website, feel good about how you're fighting unemployment."

Our goal is definitely to give administrators the control they need through the API, but I'm very willing to believe there are things we're missing. :-) Is there something specific that's not already part of our Dropbox Business API? ( https://www.dropbox.com/developers/documentation/http#teams )

I didn't see this. Huge step in the right direction.

I don't suppose there is a way to programmatically consume the activity stream and pick events to undelete, too?

I'm sorry I can't edit the smug sassiness out of my original reply.

Re: Dropbox API v2 launches

#70

Post by smarx »

awakeasleep wrote: post #69
smarx wrote: post #46

Earlier quoted context omitted.

Our goal is definitely to give administrators the control they need through the API, but I'm very willing to believe there are things we're missing. :-) Is there something specific that's not already part of our Dropbox Business API? ( https://www.dropbox.com/developers/documentation/http#teams )

I didn't see this. Huge step in the right direction. I don't suppose there is a way to programmatically consume the activity stream and pick events to undelete, too? I'm sorry I can't edit the smug sassiness out of my original reply.

It's not in v2 yet (coming soon!), but check out /log/get_events [0] in v1. I'm not sure that it will cover what you want if you're looking for file changes. That might be better served with webhooks, /files/list_folder and /files/list_folder/continue. Feel free to post on the developer forum if you want more help! [1]

[0] https://www.dropbox.com/developers-v1/business/docs#log-get-...

[1] https://www.dropboxforum.com/hc/en-us/community/topics/20020...

Post reply on HN