I want Thingifier to understand q values in the Accept header,
so that API Challenges can demonstrate real HTTP content negotiation where clients express preferred response formats.
Background
Thingifier currently supports Accept header negotiation for formats such as application/json, application/xml, */*, and unsupported media types. It should now parse quality values, e.g. application/xml;q=0.8, and choose the best supported response representation according to the client’s stated preference.
Required Behaviour
- Parse comma-separated
Accept header values.
- Support optional
q parameters on each media range.
- Treat missing
q as q=1.0.
- Treat
q=0 as “not acceptable”.
- Prefer the supported media type with the highest
q value.
- If
q values are equal, preserve the existing behaviour:
- more specific media ranges should beat wildcards,
- otherwise earlier header values should win.
- Ignore invalid or unsupported media ranges unless no acceptable supported format remains.
- Return
406 Not Acceptable when no supported representation has q > 0.
Examples
Accept: application/xml;q=1, application/json;q=0.5
Should return XML.
Accept: application/json;q=1, application/xml;q=0.5
Should return JSON.
Accept: application/xml;q=0.2, application/json;q=0.9
Should return JSON.
Accept: application/json;q=0, application/xml;q=1
Should return XML.
Accept: application/json;q=0, application/xml;q=0
Should return 406 Not Acceptable.
Accept: application/xml, application/json;q=0.5
Should return XML because missing q means 1.0.
Accept: */*;q=0.8, application/xml;q=0.9
Should return XML because it has the higher explicit preference.
Accept: application/gzip;q=1, application/json;q=0.5
Should return JSON because gzip is not a supported response representation.
Acceptance Criteria
- Existing
Accept header behaviour still works when no q values are supplied.
- API Challenges can demonstrate preference order using
q values.
- Unsupported media types do not prevent a valid lower-priority supported type from being selected.
q=0 is respected as “do not send this media type”.
- Automated tests cover JSON, XML, wildcard, unsupported media types, equal
q values, missing q, and all-supported-types-rejected cases.
I want Thingifier to understand
qvalues in theAcceptheader,so that API Challenges can demonstrate real HTTP content negotiation where clients express preferred response formats.
Background
Thingifier currently supports
Acceptheader negotiation for formats such asapplication/json,application/xml,*/*, and unsupported media types. It should now parse quality values, e.g.application/xml;q=0.8, and choose the best supported response representation according to the client’s stated preference.Required Behaviour
Acceptheader values.qparameters on each media range.qasq=1.0.q=0as “not acceptable”.qvalue.qvalues are equal, preserve the existing behaviour:406 Not Acceptablewhen no supported representation hasq > 0.Examples
Accept: application/xml;q=1, application/json;q=0.5Should return XML.
Accept: application/json;q=1, application/xml;q=0.5Should return JSON.
Accept: application/xml;q=0.2, application/json;q=0.9Should return JSON.
Accept: application/json;q=0, application/xml;q=1Should return XML.
Accept: application/json;q=0, application/xml;q=0Should return
406 Not Acceptable.Accept: application/xml, application/json;q=0.5Should return XML because missing
qmeans1.0.Accept: */*;q=0.8, application/xml;q=0.9Should return XML because it has the higher explicit preference.
Accept: application/gzip;q=1, application/json;q=0.5Should return JSON because gzip is not a supported response representation.
Acceptance Criteria
Acceptheader behaviour still works when noqvalues are supplied.qvalues.q=0is respected as “do not send this media type”.qvalues, missingq, and all-supported-types-rejected cases.