Jimmy Praet

CBSS uses the following issue types for cross-parameter validation based on the proposal in https://github.com/belgif/rest-guide/issues/113#issuecomment-1737436710: urn:problem-type:cbss:input-validation:exactlyOneOfExpected urn:problem-type:cbss:input-validation:anyOfExpected urn:problem-type:cbss:input-validation:zeroOrExactlyOneOfExpected _(instead of zeroOrOneOfExcepted, for consistency)_ urn:problem-type:cbss:input-validation:zeroOrAllOfExpected urn:problem-type:cbss:input-validation:equalExpected _(instead of expectedEqual, for consistency)_...

As these urn:problem-type:cbss:input-validation:* cross-parameter issue types are now also present in the [Belgif rest-problem library](https://github.com/belgif/rest-problem-java/blob/1801361b08a8b00fd9535b470ec6754834aa9947/belgif-rest-problem/src/main/java/io/github/belgif/rest/problem/api/InputValidationIssues.java#L49-L58), it would be good if they could be standardized under urn:problem-type:belgif:input-validation:* * urn:problem-type:belgif:input-validation:exactlyOneOfExpected = Exactly...

> Rule on OpenAPI data types is already present: Rule: Common definitions for Belgian government institutions [[oas-comdef]](https://www.belgif.be/specification/rest/api-guide/#rule-oas-comdef) Thanks, I overlooked that one somehow.

At CBSS we think it would be beneficial if the belgif problem standard would support validation issues referencing multiple parameters as follows: ```json { "type": "urn:problem-type:belgif:badRequest", "href": "https://www.belgif.be/specification/rest/api-guide/problems/badRequest.html", "title": "Bad...

I prefer the approach of deprecating the current in/name/value properties in favor of the params array. ```yaml InputValidationIssue: type: object allOf: - $ref: "#/components/schemas/Problem" # status property of Problem is...

In this article https://medium.com/isa-group/inter-parameter-dependencies-in-rest-apis-4664e901c124 a study was done where they observed that 85% of REST API's have some kind of inter-parameter dependencies. They also identified 7 common usage patterns of...

I wonder how much business impact this suggested evolution of the InputValidationProblem type would really have in practice. It seems like a trivial change when compared to earlier major changes...

Do you have any numbers on how many API's on the SocSec API Gateway already using the latest InputValidationProblem structure?

> With openapi-generator oneOf can generate some weird model classes; it doesn't even work for jax-rs currently [OpenAPITools/openapi-generator#5565](https://github.com/OpenAPITools/openapi-generator/issues/5565) , so maybe avoid it... The approach B you described in https://github.com/belgif/rest-guide/issues/108#issuecomment-1470416903...

For consistency with https://github.com/belgif/rest-guide/issues/113, where issue types like `urn:problem-type:belgif:input-validation:mutuallyExclusiveParameters` and `urn:problem-type:belgif:input-validation:incompleteParameterGroup` are proposed: maybe `urn:problem-type:belgif:input-validation:unknownParameter`? Or should we add the *Request* to the other issue types? `urn:problem-type:belgif:input-validation:mutuallyExclusiveRequestParameters`, `urn:problem-type:belgif:input-validation:incompleteRequestParameterGroup`? That becomes...