Content-type header consistency improvement

Pawel Bartkowiak
2026-03-11T15:52:18Z

Current behavior of `Content-Type` header across endpoints: * lack of error in case of lack of `Content-Type` header for Saturation Function Set and Simulation Rock Physics POST data endpoints * wrong error message in case of missing `Content-Type` for all POST requests endpoints - "The provided content-type is not supported. Please provide one of the next supported content types: \['application/json'\] * wrong status code in case of incorrect `Content-Type` value * get data and search data endpoints depend on `Content-Type` value Expected behaviour: * For **POST endpoints (requests with body)**: * Missing `Content-Type` → **400 Bad Request** → "Content-Type header is required, but was not provided" * Unsupported `Content-Type` → **415 Unsupported Media Type** → "The provided content-type is not supported. Please provide one of the next supported content types: \[\\]" * For **GET/Search endpoints (no request body)**: * `Content-Type` should not be required * Response format and schema version should be negotiated via `Accept` (including the `version` parameter), and handled consistently. Above will require corresponding changes at swagger level as well and the possibility to add corresponding headers on swagger. This issue should be handled simultaneously to [**#727**](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/rock-and-fluid-sample/rafs-ddms-services/-/issues/727)**.**