The Bucket API resource representation defines a number of fields as "writable", but which we don't already map:
cors[]
lifecycle{}
location
logging{}
versioning{}
The support for the website{} field is slightly odd (Bucket.configure_website / Bucket.disable_website), and should likely be normalized with support for the other fields.
Bucket.from_dict currently captures them all in the key's metadata attribute, but that name creates confusion with its metadata key (which stores application-defined key-value pairs).
I think it would be cleaner to map each the non-user-defined fields onto separate attributes, and propagate them to the server via the insert, and patch or update endpoints.
Bucket should also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants:
etag
id
metageneration
name
owner{}
projectNumber
selfLink
storageClass
timeCreated
The Bucket API resource representation defines a number of fields as "writable", but which we don't already map:
cors[]lifecycle{}locationlogging{}versioning{}The support for the
website{}field is slightly odd (Bucket.configure_website/Bucket.disable_website), and should likely be normalized with support for the other fields.Bucket.from_dictcurrently captures them all in the key's metadata attribute, but that name creates confusion with its metadata key (which stores application-defined key-value pairs).I think it would be cleaner to map each the non-user-defined fields onto separate attributes, and propagate them to the server via the insert, and patch or update endpoints.
Bucketshould also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants:etagidmetagenerationnameowner{}projectNumberselfLinkstorageClasstimeCreated