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

71–80 of 85 posts

Re: Dropbox API v2 launches

#71

Post by MichaelGG »

dragonwriter wrote: post #66
MichaelGG wrote: post #61

Earlier quoted context omitted.

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…

The web itself is hardly REST. Plus it's not really an API as in easily consumed by a machine. Most web pages, or the user agent, really rely on a human driving decisions.

Seriously, what's a popular API used by developers that's actually truly REST? All I usually see is various levels of awkwardness as an RPC message is sorta split up into various bits spread throughout the HTTP request.

Re: Dropbox API v2 launches

#72

Post by cllu »

One thing I cannot understand is that Dropbox API does not provide any kind of hash for files (in both v1 and v2). In contrast, Amazon Cloud Drive and Google Drive provides md5 hash, and OneDrive provides sha1Hash and crc32Hash. The lack of hash info makes custom app to compare and upload local files extremely painful.

Re: Dropbox API v2 launches

#73

Post by joshbaptiste »

MichaelGG wrote: post #60
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?

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…

Tarsnap runs fine under Cygwin.

Re: Dropbox API v2 launches

#74

Post by BinaryIdiot »

dragonwriter wrote: post #55
BinaryIdiot wrote: post #36

Earlier quoted context omitted.

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

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

No that's not true at all. Your API design should not influence the user experience but the other way around and you're unlikely to change models should you have more optimal ways to presenting things.

On paper? Sure but I've never seen anything able to be split so nicely as you describe.

Re: Dropbox API v2 launches

#75

Post by sk5t »

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.

If I had to consume an API with entity-body-having GETs, I would definitely conclude the designers had no practical experience in the field, and had read about this obscure possibility somewhere...

Re: Dropbox API v2 launches

#76

Post by sk5t »

MichaelGG wrote: post #71
dragonwriter wrote: post #66

Earlier quoted context omitted.

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

The web itself is hardly REST. Plus it's not really an API as in easily consumed by a machine. Most web pages, or the user agent, really rely on a human driving decisions. Seriously, what's a popular API used by developers that's actually truly REST? All I usually see is various levels of awkwardness as an RPC message is sorta split up into various bits spread throughout the HTTP request.

There's a lot of academic hand-wringing about what makes real REST... but not one complete example of which I am aware. I think we're past the brink of just giving up on dogmatic RESTfulness and ought just apply the term to any reasonably sane JSON RPC-style API with out-of-band documentation for humans.

Re: Dropbox API v2 launches

#77

Post by dmix »

cllu wrote: post #72

One thing I cannot understand is that Dropbox API does not provide any kind of hash for files (in both v1 and v2). In contrast, Amazon Cloud Drive and Google Drive provides md5 hash, and OneDrive provides sha1Hash and crc32Hash. The lack of hash info makes custom app to compare and upload local files extremely painful.

Git annex [1] is a far more capable solution for file syncing and remote backups. It comes with a built-in assistant which syncs directories making it an adequate Dropbox replacement.

Git annex automatically uses SHA256 on all files as the UUID (optionally set SHA512 in .gitattributes). You can PGP sign your git commits to add more verification.

Plus you dont have to trust a 3rd party with your data, as it can sync entirely over local networks via SSH, directly to a USB harddrive, and it supports encryption when using S3 or other cloud storage.

I managed to teach my non-technical girlfriend how to use it without much effort but getting business people to use it might be a hurdle.

[1] https://git-annex.branchable.com/

Re: Dropbox API v2 launches

#78

Post by brazzledazzle »

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.

I think it was released at the beginning of 2015 so I wouldn't beat yourself up about it.

Re: Dropbox API v2 launches

#80

Post by dragonwriter »

MichaelGG wrote: post #71
dragonwriter wrote: post #66

Earlier quoted context omitted.

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

The web itself is hardly REST. Plus it's not really an API as in easily consumed by a machine. Most web pages, or the user agent, really rely on a human driving decisions. Seriously, what's a popular API used by developers that's actually truly REST? All I usually see is various levels of awkwardness as an RPC message is sorta split up into various bits spread throughout the HTTP request.

> The web itself is hardly REST.

HTTP/1.0 provided the inspiration for REST, which was defined by Fielding in parallel with work on HTTP/1.1 which it informed. The web itself is very much REST, essentially being the defining instance of the architectural style.

> Plus it's not really an API as in easily consumed by a machine.

Yes, it actually is a REST API that is actually made to be, and regularly used as, an interface consumed as hypertext by machines who access requested content by locator, choose how to handle it by identified media type, identify and either directly act on or present user options to act on related content by hypermedia links, etc. Whether this is end-user software (browsers) or unattended software (Googlebot and other spiders), etc.

Post reply on HN