content negotiation - agent or server driven?

[pawel-kow]

The draft requires that

The client and server MUST support agent-driven content negotiation

RFC2616 reads

12.2 Agent-driven Negotiation With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving an initial response from the origin server. Selection is based on a list of the available representations of the response included within the header fields or entity-body of the initial response, with each representation identified by its own URI.

This is not in line with the further requirement, of using Accept and Content-Type headers which are rather typical for Server-driven Negotiation. The weak point might be of server responding with "best guess" content type not supported by the client, but this was IMHO already addressed with MUST requirement in:

Accept: Used to indicate the media type the server MUST use for the representation of objects

Own URLs for different representations would also be rather strange for an API.

Indeed some web resources [1] about content negotiation for RESTful APIs refer to agent-driven variant, but the RFC text and the other resources like [2] are rather clear that this variant would potentially include a 300 response and a second request, which is not needed here. Or do you intend a 300 response, if the client would send Accept header for both representations: xml and json?

[1] https://restfulapi.net/content-negotiation/ [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation

[mwullink]

made a mistake, now updated the text to use server-driven