Hello! What's the best way to introduce batched request handlers to the Twirp IDL? The request can just be an additional message that wraps other request(s) in a repeated field obviously, but how to encode response? Some operations might fail independently from others which might succeed. If we consider this as a Twirp error, it should have separate HTTP code, probably 207 Multi-Status, with some well-defined JSON representation for a list of successful results/errors, but currently 207 code is not considered a Twirp error code according to the spec. Other option is to encode is as a successful response and distinguish the semantics between successful and failed responses via protobuf types.
Hello! What's the best way to introduce batched request handlers to the Twirp IDL? The request can just be an additional message that wraps other request(s) in a repeated field obviously, but how to encode response? Some operations might fail independently from others which might succeed. If we consider this as a Twirp error, it should have separate HTTP code, probably 207 Multi-Status, with some well-defined JSON representation for a list of successful results/errors, but currently 207 code is not considered a Twirp error code according to the spec. Other option is to encode is as a successful response and distinguish the semantics between successful and failed responses via protobuf types.
Has anyone stumbled upon such dilemma already?