Request body parser should reject body with invalid elements

According to Salvatore, this is the last bug that needs to be fixed to get the existing unit tests running clean.

Salvatore, an you specify the unit test(s) do not pass because of this test? If so I can probably do a quick fix.

Also, what's your definition of "invalid data" here. Something that does not parse, or something that contains an unexpected parameter?

The tests that are failing are:
- create_port_badrequest_xml
- create_port_badrequest_json

They fail because the APIs return a 200 status code, while the test expects a 400 error.

The request body for the port create operation optionally contains the state for the port being created (ACTIVE or DOWN).
Therefore the API looks for it in the request body, and if it doesn't find it it just ignores the body.

This behaviour might be satisfying; however I think it would be even better if we return a 400 error when a body containing something different from the state of the port is sent to the API layer.

I took a closer look at this. It seems that the "create_network_badrequest" methods generates a 400 error and passes the unit test because the request lacks a required field ("net-name"), while the "create_port_badrequest" fails because a port has no required fields.

This led me to the conclusion that the existing API parsing logic does not seem to prevent there from being "extra" fields in the request that the API ignores, and adding such logic would be needed to get this test to pass. However, I'm not sure that is actually the right thing to do. I think this is part of a broader discussion about whether plugins should be able to use "data extension" or not. I will send mail to the list about that.

In the mean time, I would advocate for removing this test and deciding to re-insert it based on the decision we make regarding data extension.