Protobuf is a good thing, it allows c++ devs to not bother with class serialization/deserialization, is fast and .proto format is very nice. It also allows automatic data validation. But the messages are not human readable, and most importantly not human craftable. Which is a problem when you need to quickly test the response to a certain stimuli from a remote server.
The solution, as it seems to me, is to craft protobuf message, convert it to json via some library and send this, using the same library to deserialize it to protobuf on the server and back to c++.
It seems like we get best of both words: message validation, automatic class generation from .proto files and readability of json. Sure it is slower, but for my task speed is not essential. Still, is it sane? Admittedly, I have little knowledge of networking and problems that can arise from described approach. Can someone tell me if there are future problems?
Best Answer
Converting Protobuf to JSON and back is perfectly workable, as long as you can handle the performance overhead. I worked on a project where we did something like that, using JSON as the preferred format for ReST calls for lower-performance, high-friendliness. The web-layer converted to Protobuf, which the underlying services used directly. We included a direct Protobuf content-type so you could bypass the JSON encoding/decoding and use Protobuf over HTTP(S).
Certain privileged high-performance clients could access a raw socket interface that implemented a Protobuf/RPC interface onto the same services.
All worked nicely. I don't think any clients converted their protobuf to JSON - but they could have done; the schema was available, and that could have been used for migration or debugging.
EDIT:
As @RobertHarvey observes in his comment, there is a "text formatter/parser" library in protobuf, described here: https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.text_format. This provides:
For clarity, this is not a protobuf wire protocol (though I guess it could be crowbarred into being one!), but is a toolkit for helping you to work with protobuf messages as text. It probably means you wouldn't need to use JSON specifically. You could write a tool that would display a protobuf msg as text, edit it, and re-encode.