We’ve hosted Dropbox Developer Meetups in San Francisco, New York City, and Seattle where we’ve met hundreds of members of our U.S. based community. Now, it’s time to take the show on the road internationally. We announced a new engineering office in Tel Aviv earlier this year, so it seemed like the perfect place to start our global tour.
On Monday, August 27, we are hosting a Dropbox Dev Day in our shiny, new Tel Aviv office. The day will be split up into two major sections–a “Getting Started” workshop and a happy hour meetup.
Edit 06/23/2017: Deprecation timeline updated to match the one described in our recent blog post.
As of today, Dropbox API v1 is deprecated. This includes both the user endpoints (a.k.a. the Core API), and the team endpoints (a.k.a. the Business API). In order to provide our developers with the most up-to-date features and support a single, consistent platform, we’ll be turning off API v1 a year from now, on 6/28/2017.
API v2 is built thoughtfully with a consistent design and adds new endpoints and features. Additionally, we’ve open-sourced our SDK generator,
[UPDATE March 24, 2016] The official date of retirement for the Datastore API is April 29th, 2016.
Last week, we announced a preview of the new Dropbox API v2, aimed at simplifying the experience of developing with Dropbox. As part of this effort to simplify our platform, we’ve decided to deprecate the Sync and Datastore APIs over the next 12 months.
If you’re one of the majority of developers using the Core API, your app will be unaffected. For those using the Sync or Datastore API,
[EDIT June 3, 2015] This post has been updated to reflect the latest API v2 syntax.
We’ve been working on a new version of the Dropbox API for a while and it’s time to show you what we have so far. To start, we’ve implemented a select set of endpoints that highlight the big structural changes underway, and we’d like to know what you think!
Overall, we’ve simplified our use of HTTP. For example, most endpoints always use HTTP POST, including those that return structured data. Requests take JSON in the body and responses return JSON in the body.
HTTP-based APIs often encode arguments as URL path and query parameters. For example, a call to the Dropbox API’s filename search endpoint might look like:
While URL encoding seems fine for simple examples, using JSON might have some advantages.
URL paths are complicated
In the example above, the first “+” is a literal plus sign because it’s in the URL. The second “+” represents a space because it’s in the URL query component. It’s easy to confuse the two since the encoding rules are mostly the same and sometimes the library functions are name something ambiguous like “urlencode”.