René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`storage.key.Key`:  add direct support for additional resource fields ","articleBody":"The [Object API resource representation](https://cloud.google.com/storage/docs/json_api/v1/objects) defines a number of fields as \"writable\":\n- `acl[]`\n- `cacheControl`\n- `contentDisposition`\n- `contentEncoding`\n- `contentLanguage`\n- `contentType`\n- `crc32c`\n- `md5Hash`\n- `metadata{}`\n- `name`\n\n`Key.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).\n\nI 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`](https://cloud.google.com/storage/docs/json_api/v1/objects/insert), and [`patch`](https://cloud.google.com/storage/docs/json_api/v1/objects/patch) or [`update`](https://cloud.google.com/storage/docs/json_api/v1/objects/update) endpoints.\n\n`Key` should also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants:\n- `componentCount`\n- `etag`\n- `generation`\n- `id`\n- `mediaLink`\n- `metageneration`\n- `owner{}`\n- `selfLink`\n- `size`\n- `storageClass`\n- `timeDeleted`\n- `updated`\n","author":{"url":"https://github.com/tseaver","@type":"Person","name":"tseaver"},"datePublished":"2014-10-29T16:23:55.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/313/google-cloud-python/issues/313"}