generalize content-type in reframe spec #275
Conversation
There was a problem hiding this comment.
Apologies if this is a naive question (late friday, but afraid I will forget to ask on monday)
If we want to indicate it is a "generic RPC for IPFS", wouldn't application/vnd.ipfs.rpc+dag-json; version=1 do the trick?
My thinking: if we have something other than HTTP, let's say WebTransport at some point (ipfs/in-web-browsers#190), what would be the difference between below two?
application/vnd.ipfs.http+dag-json; version=1application/vnd.ipfs.webtransport+dag-json; version=1
Do we send the same dag-json in both cases, no matter if we use HTTP or WebTransport?
If so, what is the value added by having separate types?
This is a good question. In fact, since the content-type describes the encoding (dag-json) and the semantics (rpc), and not the transport (http or webtransport), the string should indeed probably just be |
Co-authored-by: Marcin Rataj <[email protected]>
I think the content-type in the REFRAME API spec should not be viewed as a part of the specific REFRAME API, but rather as a part of the RPC networking framework that the REFRAME API uses. I.e. there may be other APIs that use the same networking RPC stack. Consequently, the content-type should identify the networking framework itself rather than make a reference to the reframe API. So I am proposing we rename it from
application/vnd.ipfs.reframe+dag-json; version=1toapplication/vnd.ipfs.http+dag-json; version=1.