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)
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]
Hey if anyone from Dropbox is monitoring these comments: nice work, but there's something missing that I've been waiting for: API access to comments.
I'd love to recommend using the new Dropbox comments feature but I can't until I know there is a way of getting that data out after putting it in. I'm not entering metadata into a system that doesn't have fully programmable export. Been burned too many times.
Thanks for the feedback! This is definitely already being tracked as a feature request, but I don't have anything to share about if/when we'll add comments support to the API.
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.
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.
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.
Is there an accessible description of the API? i.e., what's driving the "code generation process"? Is that open and something I could use to generate a client for <insert my favorite language here>?
The Dropbox Badge thing looks neat [1] but I don't see any indication of an open API so that non-Microsoft applications can take advantage of it. Does anyone know if there are any plans for that?
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).
Which is why we need to get rid of the WebDAV baggage around the SEARCH method [0] and establish a general-purpose, safe/idempotent HTTP method that accepts a message body to supply parameters rather than using URL query strings; a draft RFC for such a method exists. [1]
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.
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...
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)
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.
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
Love the new features. I was hoping to see the ability to programmatically create File Requests. Looks like it might still be a while before it gets implemented.
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 in the jar.
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 RESTful...okay fine ONE RPC endpoint for the profile page's information.
I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@
> 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.)
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.
> 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.
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.
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.
I think you are really trying to dodge the question. Spiders often employ plenty of AI to try to make sense of stuff. It's not an API in any useful sense. For instance, automating Amazon.com. Humans manage fine because underlying changes and renamed URLs, input fields, etc. are ignored. A spider can't handle that (buying items, updating kindle preferences, etc.)
But for values of API that you know I'm referring to, where is one popular, truly REST API? Say, one that includes an SDK, if you need help with the definition. The fact that no one can really point out a good example means it's irrelevant to program writers.
Also, if you're saying the web is all REST essentially by definition, then so are these POST-only APIs, but they aren't. Or it's a useless tautology.
Plus I don't see any real difference in the web of HTTP1 vs 1.1, so that whole claim is suspect too. Perhaps you can elaborate exactly what HTTP1.1 added that really changed anything except some ease of use (host header, absolute URLs, keep alive).
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.
Look, if the actual REST architectural style isn't what you want, then don't use it. But that doesn't make it useful to use the term to refer to things that aren't using it. If you want to make a JSON RPC API, call it a JSON RPC API, not a REST API.
Agreed. I've no idea why everyone is so hot on saying REST. I think it's just a backlash reaction to SOAP and other complicated things, and they really mean "simpler interface" and RPC makes people think CORBA and DCOM? Or maybe the fact a PhD thesis is involved makes them feel more grown up. Like the backlash of shitty statically typed languages leading to people professing a desire for dynamic types instead of type inference. Or just buzzwordy, like people were saying SOA everywhere and now saying microservice.
The issue is not related to any personal taste or distaste for the REST style, it's that the paucity of idiomatic, complete examples and practical references has permitted the repurposing of the term "RESTful" to mean JSON RPC, and going hand-in-hand with that problem, nobody(?) is trying to implement Fielding-grade REST APIs.
Actual REST may well not be the right solution for quite a lot of the problems people have with APIs, so its good that people should not always feel obligated to use REST.
OTOH, actual REST may well be the solution for other problems, and its a lot easier to talk about solutions if we use "REST" to refer to Representational State Transfer as defined by Fielding and let all things that aren't that get names that reflect what they are, whether its JSON-RPC-over-HTTP or something else.
Its a lot harder to talk about the merits of different approaches if a wide swath of unrelated approaches that are not similar except in not being SOAP+WSDL (or, possibly, in that plus also not being Fielding's Representational State Transfer) all get lumped together as "REST".
> 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
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.
> 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.
> 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.
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.)
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.
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 "specialists" and not classical "developers".
People keep on telling me "read the spec", well there is no normative spec.
It seems like the only thing Dropbox doesn't have is the verbs.
On the other hand, I've never much cared about the "no true REST" crap that the conversation always seems to turn into. I'm too pragmatic to care if I'm adhering to someone's concept of a convention.
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?
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.
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.
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 integrate it with their Dropbox app, rather than this functionality being in a whole separate application.
Dropbox is not an advertising company like Google. They still have some of the highest fees for cloud storage around. So why do they care about seeing what's in people's files? Why not allow people to encrypt the files locally before uploading them?
And lest we forget, in the PRISM slides, Dropbox was mentioned as "coming soon". So unless they want to admit they are already part of the PRISM program, then what better way to dispel those rumors (not made any better by getting Condoleezza Rice on their board) that they are cooperating with the NSA.
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...
Not OP, but personally, 100% of the Dropbox functionality I care about is the storage and synchronization of explicitly allowed files (even if that only means "everything in ~/Dropbox"). So how the client-side synchronizer works shouldn't be a trade secret, assuming it's doing exactly what I'm paying it for and nothing else.
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 right now, they seem intent on handing your file access to governments and building systems that are insecure by design. No thanks. Open source and then we'll talk.
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.
Have you read the news this year? There's never been a worse time to be unaware and unclear of what software installed on your device does. Companies are so bad at security they lose people's private information by the million, Dropbox themselves didn't even validate passwords for a four hour window once upon a time.
It's a storage api not a spreadsheet api. Dropbox itself can't do that, but it can get you the data and you can use an xls library or program to edit them.
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."