5 ms·
> Inefficient (textual representations aren’t optimal for networks) REST APIs don't _have_ to be text-based, AFAIK. Why not just send/receive binary?
by misterbowfinger 9y ago
> Inefficient (textual representations aren’t optimal for networks)
REST APIs don't _have_ to be text-based, AFAIK. Why not just send/receive binary?
- ehsankia 9y agoSure, 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?
- cshenton 9y agoBecause bson, msgpack etc are self describing? It means a way lower barrier to entry.
- throwaway91111 9y agoI was under the impression it was trivial to store the message description in the message itself with protobuf.
- adrianmonk 9y agoI'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.
- duality 9y agoBut sadly it also means redundancy with every message sent, which must carrying this self-description.
- morecoffee 9y agoFor 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.