Re: [httpapi] Interface to inform client about supported content types

Thanks everyone for your replies and suggestions. Good to hear that there may be something in the future to use.

If I understand the draft mentioned by Mark correctly, the server could provide the information of supported content-types in POSTs with a specific Avail header (not defined yet) like so?:

Vary: Content-Type
Avail-Content-Types: application/vnd.mytype.v1; application/vnd.myextendedtype.v1

I also stumbled upon the Accept-Post response header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Post) which is not part of an RFC yet as far as I can see.

Kai

On 23.05.23, 01:56, "httpapi on behalf of Mark Nottingham" <httpapi-bounces@ietf.org <mailto:httpapi-bounces@ietf.org> on behalf of mnot=40mnot.net@dmarc.ietf.org <mailto:40mnot.net@dmarc.ietf.org>> wrote:

FYI, we're starting to talk about this in the HTTP WG (not adopted yet):
https://mnot.github.io/I-D/draft-nottingham-http-availability-hints.html <https://mnot.github.io/I-D/draft-nottingham-http-availability-hints.html>

Cheers,

> On 23 May 2023, at 2:04 am, mca <mca@amundsen.com <mailto:mca@amundsen.com>> wrote:
> 
> this topic has come up from time to time and i've not seen a solution that gained wide acceptance (pun?).
> 
> back in 2008, i revealed a set of headers (X-Accept-Types, X-Content-Types, and X-Acceptable) that i've been using to help me solve the problem.
> 
> http://amundsen.com/blog/archives/716 <http://amundsen.com/blog/archives/716>
> 
> this might not be an ideal solution but it has worked for me and it might be a seed for a more widely acceptable solution.
> 
> 
> 
> 
> Mike Amundsen
> 
> APIs, Microservices, and Digital Transformation
> 7310 Turfway Rd. Suite 550, Florence, KY, 41042
> 
> +1.859.757.1449 
> https://mastodon.social/@mamund <https://mastodon.social/@mamund> 
> https://zoom.us/j/8593726715 <https://zoom.us/j/8593726715>
> http://linkedin.com/in/mamund <http://linkedin.com/in/mamund>
> http://b.mamund.com/meetme <http://b.mamund.com/meetme>
> http://training.amundsen.com <http://training.amundsen.com>
> http://twitter.com/mamund <http://twitter.com/mamund>
> 
> 
> On Mon, May 22, 2023 at 7:04 AM Ben Bucksch <news@bucksch.org <mailto:news@bucksch.org>> wrote:
> Am 22.05.23 um 09:42 schrieb Kai Lehmann:
>> Is there a standard or common practice which allows a server to inform a client about supported content types for a specific resource at runtime?
>> Let’s say a server has the resource /myresource and provides several representations which a client can request with the Accept header or send with a POST request: GET /myresource
>> Accept: application/vnd.example.content-v1+json POST /myresource
>> Content-Type: application/vnd.example.content-extended-v1+json
>> ... the actually supported content type is depending on the resource instance and can only be determined at runtime. 
> 
> Regarding POST, which data types are accepted during an upload, that is an interesting question. I cannot answer that. (An OPTIONS request seems like a good idea to me.)
> Regarding the GET responses: Normally, the question doesn't really appear, because the client sends the Accept header (which you mentioned) which lists the content types that the client supports, and the client can also send its preferences.
> Most clients need to specifically code support for each content type, i.e. there is specific code in the client that handles a specific content type response. So, the client lists which content types it can understand. And then the server selects the intersection between the types that the client supports, and the types that the server supports, which can be specific to this instance. The server is supposed to honor the preferences that the client sends. If the client can process any kind of file type using third party programs, the client can use "*/*" as accepted content type. For example, if the client would rather have JSON or XML, but you can theoretically save any kind of file type, the client can express that, with a very low preference for "*/*".
> I don't really see a scenario which would not be covered by this. If this doesn't work in your case, could you elaborate more on your specific use case?
> Kind greetings,
> Ben
> 
>> The HTTP RFCs allow for additional payload in the response to an OPTIONS request:
>> OPTIONS /myresource
>> Accept: application/vnd.example.negotiation-v1+json
> 
> -- 
> httpapi mailing list
> httpapi@ietf.org <mailto:httpapi@ietf.org>
> https://www.ietf.org/mailman/listinfo/httpapi <https://www.ietf.org/mailman/listinfo/httpapi>
> -- 
> httpapi mailing list
> httpapi@ietf.org <mailto:httpapi@ietf.org>
> https://www.ietf.org/mailman/listinfo/httpapi <https://www.ietf.org/mailman/listinfo/httpapi>

--
Mark Nottingham https://www.mnot.net/ <https://www.mnot.net/>

-- 
httpapi mailing list
httpapi@ietf.org <mailto:httpapi@ietf.org>
https://www.ietf.org/mailman/listinfo/httpapi <https://www.ietf.org/mailman/listinfo/httpapi>