Hacker News Reader

Comment by misterbowfinger | Hacker News Reader

> Inefficient (textual representations aren’t optimal for networks)

REST APIs don't _have_ to be text-based, AFAIK. Why not just send/receive binary?

Sure, but then you'd have to write a serializer/deserializer for your messages. You could also use an existing one like Bson but then why not just use Protobuf?

Because bson, msgpack etc are self describing? It means a way lower barrier to entry.

I was under the impression it was trivial to store the message description in the message itself with protobuf.

I'm not sure I see how self-describing is a lower barrier to entry. It seems like generally the main reason why you'd want a self-describing format is if you're writing client (and server) language bindings by hand. If you have a tool to auto-generate those language bindings, you can skip that step, and there's no need to make a step easier if it's done for you automatically.

I can see where self-describing is better when it comes to side issues like debugging, exploration, or the hassle of configuring your build to generate code from the IDL files, though. But if I had to choose only one, those are lower priority to me.

But sadly it also means redundancy with every message sent, which must carrying this self-description.

For the same reason people use JSON. It's simpler, and there is a fast parser built into the browser. Even non browser clients have optimized JSON coders which is good enough.

That said, JSON is still slower and more bloated than Protobuf, and you get Protobuf for free when using gRPC.

Reply on news.ycombinator.com