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

31–40 of 85 posts

Re: Dropbox API v2 launches

#31

Post by dragonwriter »

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…

> 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 subresources in the representation, assuming the media type of the representation is one which supports that.)

Re: Dropbox API v2 launches

#32

Post by incongruity »

flyt wrote: post #23
mtgx wrote: post #21

Earlier quoted context omitted.

They don't necessarily need to do that. What they could do however, is allow files to be encrypted locally before they are synced and uploaded to their servers. The vast majority of people would still not do it anyway, but those that care would. I really like how Cryptomator works, and I think Dropbox could easily provide similar functionality, and perhaps in an even more user-friendly way, too, since they can just i…

Take a look at nCrypted Cloud for an option: https://www.encryptedcloud.com/ Realistically, though, Dropbox can't offer many of the features that differentiate them in the marketplace (collaboration, previews, sharing, etc) if all of the files they store are opaque to them. Playing in the "generic blob storage" market alongside S3 is a losing game for pretty much everybody.

AFAIK, right now, there's no convenient S3 desktop client that makes it trivial to automatically mirror and share folders, much less make client-side encryption of files trivial on top of all of the above. IMHO, that's a very viable niche... User experience matters – it's not solely about cost.

Also, about n-crypted cloud – last time I looked, the file size limit was 150 MB – that kills the utility for my team, but it's still a decent option from my experience...

Re: Dropbox API v2 launches

#33

Post by cunac »

ajkjk wrote: post #6
smizell wrote: post #5

Earlier quoted context omitted.

It is interesting that you request the /get_account link with a POST method.

As systems grow you always end up wanting to parameterize GET apis with things that you can't reasonably continue to stuff into headers, matrix params, and a wonky URL (in my experience).

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 decisions (I understand that from a purist perspective URI is opaque but well named URIs help communication with people)

Re: Dropbox API v2 launches

#34

Post by BinaryIdiot »

tacos wrote: post #29

"There are currently four SDKs for API v2: Swift, Python, .NET, and Java." And a structured, non-REST API. Aw. All grown up.

Initially I was surprised Swift, a new language, came before JavaScript. But after thinking about it you have to have it for iOS integration.

It's too bad their JavaScript SDK isn't ready yet but making HTTP calls from JavaScript is dead simple so that's not the worst thing.

Overall looks like a good set of priorities for what SDKs got done first.

Re: Dropbox API v2 launches

#35

Post by tpopp »

ohitsdom wrote: post #19
flyt wrote: post #16

Earlier quoted context omitted.

What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

There was serious concern with some evidence a few years back that the Dropbox client was touching files in folders that weren't shared. Not sure if that is what OP's concern is. But I agree with your point, the client is only one small piece of the puzzle and won't reveal much.

This concern pops up every once in a while because people like to put it out of context. Most operating systems don't allow any way to poll for file events in a specific folder only, so you either keep looping through all files in the folder looking for changes which would be an annoying resource hog or you get all events and ignore changes that don't occur in the folder of interest. It's completely fair to say that any installed application can do whatever it wants so you are concerned, but the touching files part is just people wanting to complain.

Re: Dropbox API v2 launches

#36

Post by BinaryIdiot »

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…

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

Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots".

If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls.

Google has an interesting solution for batch HTTP requests that could kinda be used in a way to batch RESTful requests but it's not the most intuitive. https://developers.google.com/drive/web/batch

Re: Dropbox API v2 launches

#37

Post by [deleted] »

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…

[deleted]

Re: Dropbox API v2 launches

#38

Post by denniskane »

BinaryIdiot wrote: post #34
tacos wrote: post #29

"There are currently four SDKs for API v2: Swift, Python, .NET, and Java." And a structured, non-REST API. Aw. All grown up.

Initially I was surprised Swift, a new language, came before JavaScript. But after thinking about it you have to have it for iOS integration. It's too bad their JavaScript SDK isn't ready yet but making HTTP calls from JavaScript is dead simple so that's not the worst thing. Overall looks like a good set of priorities for what SDKs got done first.

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.

Re: Dropbox API v2 launches

#40

Post by prodigal_erik »

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…

How do GET If-None-Match and PUT If-Match work? Do you assign an ETag that represents the current state of all those resources, so you can tell me if any have changed behind my back? Do your storages even give you the option of updating them all together atomically?
Post reply on HN