Y24-006 As PSD we would like to review the Baracoda REST API and apply consistent rules on the presence of Content-Type headers so that dependency updates do not cause unexpected changes of behaviour.

[TWJW-SANGER]

Describe the Housekeeping
As PSD we would like to review the Baracoda REST API and apply consistent rules on the presence of Content-Type headers so that dependency updates do not cause unexpected changes of behaviour.

Blocking issues
None

Additional context
A recent dependency update changed the way Baracoda validated REST API request Content-Headers.
Specifically:
curl --location --request POST ‘https://baracoda.psd.sanger.ac.uk/barcodes/RVI/new'

Has succeeded for all production versions of Baracoda and returned content encoded as application/json.
The update broke this such that without an explicit Content-Header the request failed with a HTTP 500 error.

Having reviewed StackOverflow it looks like the REST documentation specifies that accepting a POST request without an explicit Content-Header the server should assume an encoding of application/octet-stream

Tasks:

• Review REST standards to determine correct behaviour for Content-Headers for API
• Decide how we should implement the standard (I suspect we don't want to support octet-stream encoding for example)
• Document the current behaviour of the Baracoda endpoints with respect to Content-Headers
• Create a version of Baracoda that supports the correct Content-Headers AND logs when the existing non-compliant request are made.
• Document new correct behaviour on Baracoda READMe's
• Mail stakeholders that we are deprecating supporting the non-compliant REST requests and illustrating the new version that should be used. Note the old request will still work, but we will be monitoring usage.
• Release a new version of Baracoda