Since B2 cloud storage was introduced almost 3 years ago, we have been adding enhancements and new functionality to the B2 API, including capabilities such as Coors Support and Lifecycle Rules.
Today, we want to introduce a beta of version 2 of the B2 API, which formalizes rules on application keys, provides a consistent structure to provide information about all API call files, and the parameters of older requests. And clears the returned data. All version 1B2 API calls will continue to work, so no changes are required to existing integrations and applications.
The API version section of the B2 document on the Backblaze website provides details about the differences between the V1 and V2 APIs, but in the meantime here is an overview of the what, why and how of the V2 API.
In addition, V2 API calls may contain various required request parameters and / or required response data. For example, the V2 version of b2_hide_file always returns the account and bucket, while V1 returns the ledger.
The documentation for each API call will show whether there is a difference between the API versions for the given API call.
No change required for V1 applications
With the introduction of the B2 API’s V2 there will be V1 and V2 versions for every B2 API call. All applications that use the V1 API call will continue to operate with no change in behavior. In some cases, a given V2 API call will differ from its partner V1 API call as noted in the B2 API documentation.
For the remaining APIs a given V1 API call and its partner V2 calls will be the same, have the same parameters, return the same data, and have the same errors. This provides the B2 developer the flexibility to choose how to upgrade to the V2 API.
Obviously, if you want to use the functionality associated with the V2 API version, you have to use the V2 API call and update your code accordingly.
One last thing: from today, if we create a new B2 API call it will be created in the current API version (V2) and most likely not in V1.
Restricted application key
In August we introduced the ability to create restricted application keys using the B2 API. This capability can be accessed by allowing an account owner the who, how and when to restrict data in a given bucket.
This changed the functionality of many B2 API calls, so that the user could create a restricted application key that could break the 3G integration to BackBlaze B2. We later updated the affected V1 API calls, so that they could continue to work with existing 3rd party integrations.
The V2 API implements fully expected behavior when it works with restricted application keys. V1 API calls continue to work as before.
Here is an example of how the V1 API and the V2 API will function differently as it relates to restricted application keys.
B2 Java SDK and B2 Command Tool
Both the B2 Java SDK and the B2 command line tool do not currently support version 2 of the B2 API. They are being updated and will support the V2 API, with the V2 API coming out of beta and on time to GA. Both 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 to allow us to react before V2 goes into production. With every B2 integration coded differently, we want to hear from more and more developers. Try the V2 API and if you have any comments you can email our B2 beta team at [email protected] or contact Backblaze B2 support. Thank you.