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

51–60 of 85 posts

Re: Dropbox API v2 launches

#51

Post by prodigal_erik »

lucian1900 wrote: post #15
ajkjk wrote: post #6

Earlier quoted context omitted.

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

GET requests can have a body. Some clients fail at handling this and you have to use method overrides, though.

We have fifteen years worth of client and proxy implementations that do not support GET with a request body. This ill-conceived spec change violates "be conservative in what you send" just to avoid adding a new idempotent request method that actually defines usable semantics for its body.

Re: Dropbox API v2 launches

#52

Post by smarx »

aikah wrote: post #30
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…

The problem with RPC style calls is you can't take advantage of "natural" server features like caching and such. You need to re-implement all this on top of both the client and the server. I agree with your point about REST though, it's not even a standard. If it was there would be no debate about what REST is and what it isn't. It's a vague set of idea and its author himself kind of said his paper was targeted at "s…

FYI, endpoints that could actually take advantage of caching (e.g. downloading a file, preview, or thumbnail) do support HTTP GET with ETags.

Re: Dropbox API v2 launches

#53

Post by ajkjk »

cunac wrote: post #33
ajkjk wrote: post #6

Earlier quoted context omitted.

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 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 just post a json body and be done with it.

Re: Dropbox API v2 launches

#55

Post by dragonwriter »

BinaryIdiot wrote: post #36
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…

> 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 diff…

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

The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition.

Whatever is designed as part of that page, and is also a resource, is a subresource.

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

URLs align to resources in that the fact that a URL is used to access something defines it as a resource. There is nothing in REST which defines resources as only the orthogonal entities in a data mode (e.g., the loose equivalent of entities in the base tables of a relational DB model.)

You certainly in many cases, for maximum flexibility, want your resources to include those kinds of things, but there is no reason -- at least none that has anything to do with REST -- for them to be limited to them.

Re: Dropbox API v2 launches

#56

Post by dragonwriter »

prodigal_erik wrote: post #40
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…

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?

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

That would be logical, yes.

> Do your storages even give you the option of updating them all together atomically?

Depends on your backend implementation. There's no reason a composite resource needs to support PUT at all, though (that's one of the reasons that you are likely to want the representation of the composite to include URLs for each component.)

Re: Dropbox API v2 launches

#57

Post by Menge »

flyt wrote: post #20
cryptoz wrote: post #18

Earlier quoted context omitted.

Yes, they absolutely should open source their backend systems. Is the value of Dropbox really in their source code? I doubt it. They want my files, all of them, but they won't tell me what they're doing with the files or how their code works? Everything about this should be open source, and I won't ever use it until it is. Also they should make a lot more effort towards promising privacy and security. As it stands ri…

You aren't obligated to be a customer of Dropbox. There are plenty of other services, either self-run or not, that caters to people that value baseless paranoia over functionality and usability.

> baseless paranoia

You mean like this: http://www.theregister.co.uk/2015/06/10/condoleezza_rice_to_...

But a paranoid board director is reasonable, or?

Re: Dropbox API v2 launches

#59

Post by nulltype »

BinaryIdiot wrote: post #36
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…

> 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 diff…

I think some of these problems are solved by HTTP/2 multiplexing.

My experience at least with using REST for APIs seems to agree with yours. REST APIs, like traditional OO programming, seem to only help in a small number of situations. I've seen some really complicated things in the name of "RESTful"ness, like crazy Accept headers for different versions of the API. And like you pointed out, each developer seems to have their own idea of what REST means.

Approaching the API design from the other direction seems better. What is HTTP offering you that is better than just using a socket? It's got a request/response thing with message framing, some handy out-of-band stuff with the headers, there's HTTPS support, it works directly with browsers, and sometimes you can even get it to work through a proxy. HTTP requests are also supported pretty easily (more easily than socket stuff maybe) in most languages.

Then, using features from HTTP where they make sense can be nice (maybe some of the status codes or ETags are useful?), but throwing the whole nebulous REST framework in there without considering how well it matches the problem or how it adds to the complexity of the solution is not a good idea.

Re: Dropbox API v2 launches

#60

Post by MichaelGG »

flyt wrote: post #16
cryptoz wrote: post #11

Is the Dropbox client fully open source yet? I won't use a spying tool that hires international spies to be on the board if they continue to be closed-source and intent on spying. Their new SDKs seem to be open source - why not their main client product?

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?

It'd go a long way to re-establishing trust. Thinking about their "Employees cannot access your data" statement, which really meant the exact opposite. And how they didn't immediately back down and apologize, but sorta tried to defend it.

OTOH, since your data is accessible to anyone after they push "return true" as their auth mechanism, I guess it doesn't really matter. If they offered proper encrypted storage, it'd be much more important.

Though even without encryption, a closed-source client that auto-updates leaves one big hole: They can push an update to specific users or activate code for them. With an open source client, that part could be mostly avoided.

Unfortunately, Tarsnap seems to be the only contender in this area (trustworthy backups). On Windows, this means using VMware shared folders.

Post reply on HN