4 ms·
I like the simplicity of the library. I haven't tried it yet, but this behavior is a bit unfortunate choice > If there is an error, it will be JSON encoded, in
by doh 9y ago
I like the simplicity of the library. I haven't tried it yet, but this behavior is a bit unfortunate choice
> If there is an error, it will be JSON encoded, including a message and a standardized error code.
Why not to return standard protobuf error when the source was a protobuf? It massively complicates things when you have to expect errors in one format and responses in the other.
- spenczar5 9y agoIt’s important for errors to be human-readable off the wire. If they were proto-encoded, you couldn’t get at them easily with tcpdump, and you couldn’t read erroring response bodies from curl, and you couldn’t read errors shipped to stuff like rollbar. Hopefully, the complexity is encapsulated by the generated client.
- nickspacek 9y agoWhat about allowing/respecting an Accept header in the Request? In @doh's case, if the client only specified Accept: application/protobuf that would override the default behavior of returning JSON encoded errors.
- spenczar5 9y agoThat’s a pretty good idea. It does expand the complexity of the client a bit, but at least it’s in an opt-in way so it doesn’t strictly need to be done for cross-language clients. But what would the benefit(s) to users be? If they are deserializing a protobuf error, they are almost certainly using a generated client, so I don’t think they will know or care how the error was encoded. (This might be better as a github issue to keep a visible record of the design for others.)
- doh 9y agoI think it depends who the user is in your case. In mine it's the developer who has to work with Twirp outside of the standard libraries (maybe different language, maybe just wants to incorporate it in their own code, ...). I also like when things are consistent without surprising behavior.