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
We prescribe some default encoding pairs for JSON, e.g. ["base64", string] for bytes, ["rfc3339", string] for DateTime-like scalars.
Additionally, we've said that emitters are meant to give encodings a treatment that goes something like:
When an emitter encounters an encoding pair [Encoding, Type] for a given canonical type Source, emitters should resolve this by modeling Sourceas if it were Type and emitting a warning advising that the emitter cannot handle the encoding and will instead require the client/server consumer/implementor to handle the wire type directly.
There are a couple of problems with this approach:
The default encoding of a type depends on the MIME type of serialization. A type may be subject to multiple different serializations in the same context. Consider:
In this example, the output serialization format of the body should depend on the Accept header submitted by the client and/or the type chosen by the service implementation.
In JSON, utcDateTime has a default encoding pair ["rfc3339", string], but in Protobuf, utcDateTime has a built-in representation in Google's library. Supposing an emitter does not implement the "rfc3339" encoding for utcDateTime, how should it represent the type of Data#created in the response? The default treatment for JSON requires created: <repr string>, but the treatment for "application/x-protobuf" would require created: <repr utcDateTime>
When emitters implement support for additional encodings, this will manifest as a breaking change in generated code. The type will quietly be replaced with an incompatible type when/if the emitter does eventually support the unknown encoding (e.g. created: string may eventually become created: Date or created: Temporal.Instant, and these types are nonoverlapping, leading to breaking changes in both input and output assignability of <repr Data>.
The text was updated successfully, but these errors were encountered:
We prescribe some default encoding pairs for JSON, e.g.
["base64", string]
for bytes,["rfc3339", string]
for DateTime-like scalars.Additionally, we've said that emitters are meant to give encodings a treatment that goes something like:
There are a couple of problems with this approach:
The default encoding of a type depends on the MIME type of serialization. A type may be subject to multiple different serializations in the same context. Consider:
In this example, the output serialization format of the body should depend on the
Accept
header submitted by the client and/or the type chosen by the service implementation.In JSON,
utcDateTime
has a default encoding pair["rfc3339", string]
, but in Protobuf,utcDateTime
has a built-in representation in Google's library. Supposing an emitter does not implement the"rfc3339"
encoding forutcDateTime
, how should it represent the type ofData#created
in the response? The default treatment for JSON requirescreated: <repr string>
, but the treatment for"application/x-protobuf"
would requirecreated: <repr utcDateTime>
When emitters implement support for additional encodings, this will manifest as a breaking change in generated code. The type will quietly be replaced with an incompatible type when/if the emitter does eventually support the unknown encoding (e.g.
created: string
may eventually becomecreated: Date
orcreated: Temporal.Instant
, and these types are nonoverlapping, leading to breaking changes in both input and output assignability of<repr Data>
.The text was updated successfully, but these errors were encountered: