Revisit Model negotiation : header vs query
Source: Mayo Clinic ( Davide Sottara)
API4KP uses a tunneling approach where 'models' of various nature are wrapped in an API4KP "KnowledgeCarrier" object that adds some necessary metadata about the model.
Implementations that require transport (e.g. based on ReSTful web services) face two problems:
- the serialization format of the wrapper (JSON, XML or else)
- the representation and serialization of the model (in various languages, across serializations and formats)
The former is a classic content negotiation problem, and is expetcted to be handled in the standard way, using Accept-* and Content-* headers
The latter is a similar but distinct model negotiation problem. The standard mandates not to use the content negotiation headers - so that, for example, a BPMN+XML model can be serialized and embedded in an API4KP+JSON KnowledgeCarrier.
Insteadd, API4KP model negotiation defines an "X-Accept" header for requests, and uses the KnowledgeCarrier body itself for the analogue of the Content-Type response.
The use of a header, as opposed to a query parameter, has pros and cons, and should be discussed.
Ultimately, it comes down to the ability to provide a (persistent) URL to a specific knowledge artifact, using a primary identifier composed by the ID of the carried knowledge Asset, plus a coded identifier of the artifact's form
(1) keep xAccept as it is
(2) replace xAccept w/ qAccept
(3) add qAccept as an optional parameter, together with xAccept
I am strongly inclined towards (3), for this reason:
return (any) "canonical" model form
/carrier ? qAccept=formB
return model form B specifically
retrieve or generate formB using any form available
/carrier ? qAccept=formA
retrieve formA, and use it to generate formB if not the same
Reported: API4KP 1.0b2 — Thu, 13 Jul 2023 19:01 GMT
Updated: Thu, 13 Jul 2023 19:03 GMT