Re: [media-types] Re: Rethinking Media Types

Hi Roy,
On Friday, January 10th, 2025 at 12:25 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> > On Jan 9, 2025, at 10:00 AM, Rahul Gupta <cxres@protonmail.com> wrote:
> > 

> > Hi Michael,
> > 

> > I am not at all suggesting that media types are not already useful. If anything, quite the opposite, they are necessary to REST. To quote Roy Fielding <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven>, "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types".
> 

> 

> To clarify, REST requires some form of standard typing mechanism to declare media types because that is how senders communicate an intended processing mechanism (when applicable). That's part of the style.
> 

> One architecture in that style is defined by HTTP, which specifically defines internet media types for that purpose. But, again, that purpose is to express an intended processing mechanism. Not a data format, though of course many processing mechanisms are specific to a standard data format.
> 

> This can be clearly seen in the fact that many media types are applicable to the same sequence of bits, just as application/octet-stream can be used as the type for any byte-delimited data format.
> 

> Internet media types are also used by many other protocols, with other architectural styles, though in most cases (like email) it is generally true that the media type indicates an intended processing model rather than (just) a data format.


Thank you for that clarification and explainer. Armed with a better understanding and vocabulary, I hope I might be able to explain my concerns better...


> 

> 

> > My assertion here is that content negotiation can be more powerful with better evolvability characteristics, if media types could be made modular. It will make it easier to define formats with greater specificity, without a proliferation of media-types (which comes with a registration burden).
> 

> 

> There are three problems with that assertion:
> 

>  1) Internet media types are already defined and deployed, as is;


It is not my intention to suggest that we replace media types, but to augment the content negotiation mechanism of HTTP (which will still use existing media types) and look to do it in manner that is backwards compatible. See under point 3.


>  2) The actual data format(s) of a media type are defined by reference, regardless; and,
>  3) Any focus on modularity of data format ignores the fact that the media type's primary purpose is to indicate an intended processing mechanism, which is not defined by a modularity of formats. In fact, a single media type could include dozens of distinct data formats, assuming they have the same purpose and can be internally parsed by the recipient.


The shortcomming that I see is that HTTP uses a string as reference to intended processing mechanism which has to be then registered. When servers want to communicate subtle differences o processing mechanism or multiple data formats in representation or same data format in a different envelopes or multiple envelopes, might we instead communicate a recipe that builds upon combination of media types, ie we communicate multiple references in some agreed structured form which clients can decode to construct the intended processing mechanism (that's what I meant by modularity; apologies if my limited language created another impression). This way the combinatorial explosion (the reason why we need sequences of suffixes) happens in the metadata being communicated in responses, rather than registrations of media types. More detailed instructions will mean more metadata but fewer and simpler registered media types.


> 

> ....Roy
> 



BR/Rahul