Since B2 cloud storage was introduced nearly 3 years ago, we’ve been adding enhancements and new functionality to the B2 API, including capabilities like CORS support and lifecycle rules. Today, we’d like to introduce the beta of version 2 of the B2 API, which formalizes rules on application keys, provides a consistent structure for all API calls returning information about files, and cleans up outdated request parameters and returned data. All version 1 B2 API calls will continue to work as is, so no changes are required to existing integrations and applications.
The API Versions section of the B2 documentation on the Backblaze website provides the details on how the V1 and V2 APIs differ, but in the meantime here’s an overview into the what, why, and how of the V2 API.
What Has Changed Between the B2 Cloud Storage Version 1 and Version 2 APIs?
The most obvious difference between a V1 and V2 API call is the version number in the URL. For example:
https://apiNNN.backblazeb2.com/b2api/v1/b2_create_bucket
https://apiNNN.backblazeb2.com/b2api/v2/b2_create_bucket
In addition, the V2 API call may have different required request parameters and/or required response data. For example, the V2 version of b2_hide_file
always returns accountId
and bucketId
, while V1 returns accountId
.
The documentation for each API call will show whether there are any differences between API versions for a given API call.
No Change is Required For V1 Applications
With the introduction of V2 of the B2 API there will be V1 and V2 versions for every B2 API call. All applications using V1 API calls will continue to work with no change in behavior. In some cases, a given V2 API call will be different from its companion V1 API call as noted in the B2 API documentation. For the remaining API calls a given V1 API call and its companion V2 call will be the same, have identical parameters, return the same data, and have the same errors. This provides a B2 developer the flexibility to choose how to upgrade to the V2 API.
Obviously, if you want to use the functionality associated with a V2 API version, then you must use the V2 API call and update your code accordingly.
One last thing: beginning today, if we create a new B2 API call it will be created in the current API version (V2) and most likely will not be created in V1.
Standardizing B2 File Related API Calls
As requested by many B2 developers, the V2 API now uses a consistent structure for all API calls returning information about files. To enable this there are some V2 API calls that return additional fields, for example:
- b2_hide_file now returns
accountId
,bucketId
. - b2_list_file_names now returns
accountId
,bucketId
. - b2_list_file_versions now returns
accountId
,bucketId
. - b2_list_unfinished_large_files now returns
action
(always “upload”),contentLength
(always null), andcontentSha1
(always null). - b2_start_large_file now returns
action
(always “upload”),contentLength
(always null), andcontentSha1
(always null).
Restricted Application Keys
In August we introduced the ability to create restricted applications keys using the B2 API. This capability allows an account owner the ability to restrict who, how, and when the data in a given bucket can be accessed. This changed the functionality of multiple B2 API calls such that a user could create a restricted application key that could break a 3rd party integration to Backblaze B2. We subsequently updated the affected V1 API calls, so they could continue to work with the existing 3rd party integrations.
The V2 API fully implements the expected behavior when it comes to working with restricted application keys. The V1 API calls continue to operate as before.
Here is an example of how the V1 API and the V2 API will act differently as it relates to restricted application keys.
Set-up
- The B2 account owner has created 2 public buckets, “Backblaze_123” and “Backblaze_456”
- The account owner creates a restricted application key that allows the user to read the files in the bucket named “Backblaze_456”
- The account owner uses the restricted application key in an application that uses the b2_list_buckets API call
In Version 1 of the B2 API
-
- Action: The account owner uses the restricted application key (for bucket Backblaze_456) to access/list all the buckets they own (2 public buckets).
- Result: The results returned are just for Backblaze_456 as the restricted application key is just for that bucket. Data about other buckets is not returned.
While this result may seem appropriate, the data returned did not match the question asked, i.e. list all buckets. V2 of the API ensures the data returned is responsive to the question asked.
In Version 2 of the B2 API
-
- Action: The account owner uses the restricted application key (for bucket Backblaze_456) to access/list all the buckets they own (2 public buckets).
- Result: A “401 unauthorized” error is returned as the request for access to “all” buckets does not match the restricted application key, e.g. bucket Backblaze_456. To achieve the desired result, the account owner can specify the name of the bucket being requested in the API call that matches the restricted application key.
Cleaning up the API
There are a handful of API calls in V2 where we dropped fields that were deprecated in V1 of the B2 API, but were still required. So in V2:
- b2_authorize_account: The response no longer contains
minimumPartSize
. UsepartSize
andabsoluteMinimumPartSize
instead. - b2_list_file_names: The response no longer contains
size
. UsecontentLength
instead. - b2_list_file_versions: The response no longer contains
size
. UsecontentLength
instead. - b2_hide_file: The response no longer contains
size
. UsecontentLength
instead.
Support for Version 1 of the B2 API
As noted previously, V1 of the B2 API continues to function. There are no plans to stop supporting V1. If at some point in the future we do deprecate the V1 API, we will provide advance notice of at least one year before doing so.
The B2 Java SDK and the B2 Command Tool
Both the B2 Java SDK and the B2 Command Line Tool, do not currently support Version 2 of B2 API. They are being updated and will support the V2 API at the time the V2 API exits Beta and goes GA. Both of these tools, and more, can be found in the Backblaze GitHub repository.
More About the Version 2 Beta Program
We introduced Version 2 of the B2 API as beta so that developers can provide us feedback before V2 goes into production. With every B2 integration being coded differently, we want to hear from as many developers as possible. Give the V2 API a try and if you have any comments you can email our B2 beta team at b2beta@backblaze.com or contact Backblaze B2 support. Thanks.