Re: [media-types] Rethinking Media Types

Hi Owen,

That's partly built into the design of HTTP (media-types as a reference) and partly in the nature of applications (limited processing capabilities). I am not sure why such inference would even be an issue? Furthermore, servers can also send an Accept header field, allowing for Request Content Negotiation https://www.rfc-editor.org/rfc/rfc9110.html#name-request-content-negotiation. It would be absurd for the server which is able to serve a user-agent preference as indicated by Accept-* header fields to serve anything else (even if technically possible) because it is probably useless to the user-agent. 

BR/Rahul


On Friday, January 10th, 2025 at 1:52 AM, Owen Rubel <orubel@gmail.com> wrote:

> Not to take this off topic BUT since we are talking about media, I would add when defining 'content-type' you can INFER 'accept'
> 

> Over 90% of requests EXPECT to return the same format as is being requested.
> 

> It is actually an aberration to request in one format and send in a different. Breaks ASSUMED LOGIC.
> 

> Owen Rubel
> orubel@gmail.com
> 

> On Thu, Jan 9, 2025 at 10:58 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.
> > 

> > 

> > > 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;
> > 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.
> > 

> > ....Roy
> >