74
votes

JSON has application/json as a standard. For protobuf some people use application/x-protobuf, but I saw something as odd as application/vnd.google.protobuf being proposed. Do we have an RFC or some other standard that I can use as a reference for this?

1
groups.google.com/forum/#!topic/protobuf/VAoJ-HtgpAI is probably where the vnd one comes from; no, I'm not aware of any change since that discussion, and no: I'm not aware of any standard - Marc Gravell
looks like protorpc switched to application/octet-stream: github.com/google/protorpc/commit/… - Marc Gravell
there is an IEFT draft tools.ietf.org/html/draft-rfernando-protocol-buffers-00 that suggests application/protobuf, however: that is only a draft and kinda looks like it didn't go anywhere and is now expired - Marc Gravell
It most cases, knowing that some data is a protobuf isn't particularly useful; if you want to know the type at all, you want to know what protobuf type it is. So really, every user of protobuf needs their own content-type. - Kenton Varda
@KentonVarda Knowing data is protobuf is useful, even without identifying the nature of the messages. For example, consider the value of content type in content negotiation between XML or JSON - even though they're both useless if you can't interpret their contents. It's equally useful for more than two choices, e.g. XML or protobuf or JSON or LISP (or would it be LISPON?). :-) - Edward Brey

1 Answers

35
votes

There's an expired IETF proposal that suggests application/protobuf. It does not address the question how the receiving side could determine the particular message type. Previous discussions suggested using a parameter to specify package and message, e.g. application/protobuf; proto=org.some.Message

In practice, the types you listed seem to be indeed the ones in use, for example the monitoring system Prometheus uses application/vnd.google.protobuf, and the Charles web debugging proxy recognizes application/x-protobuf; messageType="x.y.Z".