operation response schema and response example behaves differently

[codeasashu]

Description

I am depening on response_schema and example_response extensively in my custom resolver. I am expecting them to give out schema and example for same operation in same fashion, but they are not.

Consider hello world yaml

from connexion.mock import MockResolver

class CustomResolver(MockResolver):
    def mock_operation(self, operation, *args, **kwargs):
        response, code = operation.example_response() # Returns "hello dave!", 200
        schema = operation.response_schema() #returns {} 

I can understand that we need to specify status_code and content_type for the schema, however https://github.com/zalando/connexion/blob/master/connexion/operations/abstract.py#L283 seems to be using default content type in case one fails to specify. Why then, are we not using same for status_code? Something like

status_code = status_code or sorted(self._responses.keys())[0]

Expected behaviour

response_schema should give out default appropriate schema found, even when status_code is not mentioned (increasing status code can be used to determine first matching schema).

Actual behaviour

response_schema returns nothing when status_code is not mentioned. However, example_response does.

Additional info:

Output of the commands:

• python --version Python 3.7.4
• pip show connexion | grep "^Version\:" Version: 2.4.0

[dtkav]

It makes sense to me that when we are trying to generate an example we can guess very liberally about what the result might be. However, guessing at the response schema could cause all kinds of havoc - we might use it to validate the response. My guess is that your change would cause serious breakage for folks using the "validate_responses" option, as connexion might suddenly start validating responses with guessed schemas. What do you think?

[RobbeSneyders]

It would probably make more sense to make the status_code required, since every response schema needs to be under a status_code in both swagger 2 and openapi 3. You can still implement a mechanism to fetch the lowest response code outside of this function.

[codeasashu]

@RobbeSneyders The status_code is required, yes and your comment makes sense. However, the same goes for responses' examples. They too are dependent on status code the same way their schemas are.

This, in a sense, is breaking the uniformity between schema and examples. Either both have to have same signature/derivates, or the same should be expected from both. This is really confusing for me.