Generated *View<'a> types implement ViewEncode (proto-binary) but not serde::Serialize, so a consumer that wants to emit JSON from a borrowed view has to to_owned() first.
In connect-rust this surfaces as an asymmetry in the handler API: a handler can return a view body for proto clients (zero-copy via ViewEncode), but the same handler returns Code::Unimplemented to a JSON client because there's no way to serialize the view. The owned type round-trips fine in both codecs.
// connectrpc::__codegen::encode_view_body, simplified:
match codec {
CodecFormat::Proto => Ok(v.encode_to_bytes()),
CodecFormat::Json => Err(ConnectError::unimplemented(
"view-body responses do not support the JSON codec; \
return the owned message type for JSON-serving handlers",
)),
}
Emitting impl Serialize for FooView<'_> (gated behind the existing json feature, like the owned types) would close the gap. The view already has all the field data; the impl is structurally the same as the owned one minus the Option/presence wrapping differences.
This is larger than the other two asks (touches every view emitter) so flagging it as a feature request rather than a 0.4.x candidate, unless adjacent serde work is already planned.
Generated
*View<'a>types implementViewEncode(proto-binary) but notserde::Serialize, so a consumer that wants to emit JSON from a borrowed view has toto_owned()first.In connect-rust this surfaces as an asymmetry in the handler API: a handler can return a view body for proto clients (zero-copy via
ViewEncode), but the same handler returnsCode::Unimplementedto a JSON client because there's no way to serialize the view. The owned type round-trips fine in both codecs.Emitting
impl Serialize for FooView<'_>(gated behind the existingjsonfeature, like the owned types) would close the gap. The view already has all the field data; the impl is structurally the same as the owned one minus theOption/presence wrapping differences.This is larger than the other two asks (touches every view emitter) so flagging it as a feature request rather than a 0.4.x candidate, unless adjacent serde work is already planned.