Re: [media-types] Rethinking Media Types

You mean the capability is there. Products dont IMPLEMENT this way however.

I focus HEAVILY on optimization and this is a simple optimization
every developer can do... but they dont. Their tools, frameworks, services
don't. And we have such a badly informed populace of AI snippet developers
that they probably never will.

I would love to know of some that do (out of the box) if I am wrong.

Owen Rubel
orubel@gmail.com


On Fri, Jan 10, 2025 at 7:29 AM Rahul Gupta <cxres@protonmail.com> wrote:

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