> Backblaze as I mentioned in another comment will be a bad idea due to the poor S3 compatible interface
Backblaze released an S3 compatible API recently: https://www.backblaze.com/b2/docs/s3_compatible_api.html
We're ALWAYS curious about any issue customers see, so if there is something specifically missing you use, we both want to hear about it, and we might be able to add it. Even if it doesn't help you right away, maybe it will help somebody else a few months down the road who might need the same feature.
We know we're compatible with Veeam backups (which only go through S3 APIs) for instance, and we continue to maintain that. We added the "S3 Object Lock" specifically for this particular vendor. So if you are missing one or two APIs, let us know!
If you want to use Amazon S3 APIs, you do not call ANYTHING that is documented on the Backblaze website, and you especially should not call "b2_get_upload_url" because that is a B2 native API, not an Amazon S3 API. You can always tell if you are using "B2 Native" if the call starts with "b2_" -> then that has literally nothing to do with Amazon S3 compatibility, it is the custom Backblaze protocol.
If you want to find out about Amazon S3 APIs (which you use to communicate to Backblaze's Storage Cloud or Amazon S3) then you can start here: https://docs.aws.amazon.com/general/latest/gr/signature-vers... Make sure you stay ENTIRELY on the Amazon website, and only read Amazon documentation, and use the APIs Amazon talks about (but of course you are doing all of this communicating with the Backblaze Storage Cloud backend). If any of that fails in your application, or in incompatible, PLEASE LET US KNOW!!
So if you HAPPEN to find something is more clear with the B2 API, it's fine to use those calls on a bucket. If you find something is more clear in the S3 API, it's also fine to use those calls. The bucket won't get confused. :-)