Better handling of raw bytes

[broady]

Given this field in a discovery doc:

    "AsymmetricDecryptRequest": {
      "description": "Request message for KeyManagementService.AsymmetricDecrypt.",
      "id": "AsymmetricDecryptRequest",
      "properties": {
        "ciphertext": {
          "description": "Required. The data encrypted with the named CryptoKeyVersion's public\nkey using OAEP.",
          "format": "byte",
          "type": "string"
        }
      },
      "type": "object"
    },

This gets generated as:

type AsymmetricDecryptRequest struct {
    // Ciphertext: Required. The data encrypted with the named
    // CryptoKeyVersion's public
    // key using OAEP.
    Ciphertext string `json:"ciphertext,omitempty"`

The server accepts a base64-encoded string as the data, but we don't tell users that they need to encode it themselves.

Ideally, we'd just generate this as []byte, which encoding/json actually encodes as a b64-encoded string.

Is this a worthwhile breaking change?

If not, we should at least generate some docs/example on base64-encoding the package?

[broady]

/cc @bradfitz if he has an opinion about this.

etags are the most prevalent use of this type, and I'd hope that most usage is pretty opaque:

pseudocode:

o := get(foo)
o.bar = 1
patch(foo, o, etag=o.etag)

[jeanbza]

There are analogies between this and the recent integer issue, in which we decided to keep int fields instead of specifying int64, int32, etc. to avoid a major breaking change. I think that same logic can be applied here. WDYT?

[broady]

@jadekler +1

Two options to improve this without making a breaking change:

• improved docs/examples
• getters/setters

(or combination/both)

More generally, maybe we should collect these types of issues under a "v2" label?