You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"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?
The text was updated successfully, but these errors were encountered:
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?
Given this field in a discovery doc:
This gets generated as:
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?
The text was updated successfully, but these errors were encountered: