Create abstract validator classes

[RobbeSneyders]

As promised, an AbstractRequestBodyValidator class. This has 2 advantages:

• Groups all common code
• Provides a base for custom validators

Looking at the remaining logic in the subclasses, I'm quite happy with the current abstraction. A lot of the complexity comes from substituting the default body when no body is received.

I'll leave some additional comments in-line.

[RobbeSneyders]

Also needs to be added for each property separately, so if a body is sent without the property, the default value is added.

[RobbeSneyders]

Not completely happy with this. The __init__ arguments for the validators are fixed in the request_validation , so it doesn't really make sense that individual validators define additional parameters.
On the other hand, we do support form data specifically, so I can live with it. Open for better solutions though.

[Ruwann]

Don't have a better idea at the moment :)

[RobbeSneyders]

We should provide a similar base class for the ResponseBodyValidators.

[coveralls]

Pull Request Test Coverage Report for Build 4308721132

• 151 of 158 (95.57%) changed or added relevant lines in 9 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.7%) to 92.997%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
connexion/validators/abstract.py	76	78	97.44%
connexion/validators/json.py	35	40	87.5%

Files with Coverage Reduction	New Missed Lines	%
connexion/lifecycle.py	2	86.08%

Totals
Change from base Build 4270694070:	0.7%
Covered Lines:	3267
Relevant Lines:	3513

---

💛 - Coveralls

[RobbeSneyders]

Added an AbstractResponseBodyValidator class and aligned the Request one. Commits are atomic, which is useful to review.

[Ruwann]

Just realized now that we are still using a uri_parser for form data (i.e. request body), which is not ideal.
Can't remember completely, but it's actually to parse arrays and/or parameters that are specified multiple times?

[RobbeSneyders]

The form data body is the same format as a query string, just sent as body. So I think it's logical to use the uri_parser here as well.

[Ruwann]

Yes, true for the case of application/x-www-form-urlencoded but for multipart/form-data the parameters are sent in different parts instead of query string.
But indeed, not necessarily as surprising as I thought (URI <> body) :)

[Ruwann]

Don't have a better idea at the moment :)

[Ruwann]

Why can we delete this one now?

[RobbeSneyders]

In query parameters it's impossible to represent null there:

• ?key= could be interpreted as an empty string
• ?key is not clear as discussed in this issue:
  Boolean query parameter with allowEmptyValue responds 400 insisting on =true  #1538

So connexion supports "null" and "None" as null values, so you can send:

• ?key=null
• ?key=None
  (I'm actually not a fan of supporting "None" here, since it's Python specific, but if we still need to support "null", the benefit of dropping it is probably too small.)

In json, null can be represented:

{
    "key": null
}

or for a null body (eg. try json.dumps(None)):

"null"

So we don't need to support "None" here.
We actually don't need to support "null" here either, since we should always parse it before checking, in which case it's parsed to None. This is why I replaced all is_null(body) checks in the body validators with body is None.