Open dsilhavy opened 5 months ago
My reading of 422 Unprocessable Content is that is applies in cases where the syntax is valid but the semantic is not.
This case falls in the crack between a syntax error and a semantic error. While the invalid enumerated value is technically valid in the the OpenAPI YAML syntax, our particular implementation doesn't support it because it is not a valid value in the current version of the specification. To my mind that feels more on the side of a syntax error, but one that isn't policed automatically by the OpenAPI YAML definition.
I would therefore lean slightly more towards a 400 Bad Request client error response code in this case.
This issue is actually part of a wider lack in the TS 26.512 YAML specifications. Many API operations do not have a comprehensive list of HTTP error responses. This has been addressed in TS 26.510 Rel-18. The question is whether it's worthwhile going back and fixing in Rel-16 and Rel-17.
In practice, implementations are free to return whichever HTTP response codes they like, and recent improvements in the handling of enumerated types in the 5GMS AF implementation mean that we can now automatically send an error if an unrecognised enumerated value is encountered.
We probably need to broaden out the scope of this issue to improve all HTTP responses across all M1 and M5 APIs.
But we may only address Rel-17.
Description
As part of the
PolicyTemplate
object defined inTS26512_M1_PolicyTemplatesProvisioning.yaml
achargingSpecification.sponStatus
of typeTS29514_Npcf_PolicyAuthorization.SponsoringStatus
may be defined. TheSponsoringStatus
string is defined as follow:Although any value of type
string
is a valid value for this parameter, implementations might only support one of the two possibleenum
values, namelySPONSOR_DISABLED
andSPONSOR_ENABLED
. In cases in which a value is used that does not correspond to one of the aforementionedenum
values, it is desirable to send an error code to the sending entity to signal that the request contained unsupported or invalid payload.The
put
operation to update an existing policy template defined inTS26512_M1_PolicyTemplatesProvisioning.yaml
only allows two response codes, namely204
and404
. Both are not well suited for the described use case in which an unssuported payload is provided.Suggested solution
To handle use cases in which an invalid or unsupported payload is sent as part of the
put
operation, additional response codes should be supported. For instance, a422
response code allows signaling unprocessable content and might be a good option to signal unsupported parameters in the payload: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422Related issues